ISO 27001 A.8.28: Secure Coding

To satisfy ISO 27001 A.8.28, apply secure coding principles to how your team writes software: adopt language-specific coding standards, plan security in before coding starts, use vetted components and manage dependencies, run static analysis (SAST) and secret scanning in the pipeline, review code for security, and keep a maintained set of secure coding rules developers can point to. A.8.28 is one of the controls introduced in the 2022 revision, and the action teams most often get flagged on is running the scanners without a documented coding standard behind them, so the tooling exists but nothing states the rules the code is supposed to meet.

A.8.28 is a Technological control in Annex A of ISO/IEC 27001:2022. It maps fully to SOC 2 CC8.1, so a team that already runs SOC 2 change management and development controls has most of the evidence an ISO 27001 auditor will ask for.

What is ISO 27001 A.8.28?

ISO 27001 A.8.28, titled Secure coding, requires that secure coding principles be applied to software development. The intent, as expressed in ISO/IEC 27001:2022, Annex A, is that code is written to avoid the common flaw classes that lead to vulnerabilities, and that the practices for doing so are defined and applied consistently rather than left to individual developer habit.

A.8.28 is one of the controls introduced in the 2022 revision of the standard. Earlier versions of ISO 27001 addressed secure development at the life cycle level, but the 2022 edition named secure coding as its own control to give the coding stage explicit weight. A.8.28 does not prescribe a language, a linter, or a scanner. What it expects is that the organization has adopted secure coding standards for the languages and frameworks it uses, applies them before, during, and after writing code, and can show that the standards are maintained and followed.

How do you implement A.8.28?

Adopt secure coding standards for your stack, then wire them into how developers already write and merge code. Because A.8.28 governs the coding practice rather than any single host, the actions are the same whether the application runs in the cloud or on-prem. Run this sequence:

1. Adopt secure coding standards for your languages. Choose a coding standard for each language and framework in use, so that common flaw classes (injection, broken access control, unsafe deserialization, insecure cryptographic use) are handled the same way by everyone. Reference an established source such as the OWASP coding guidance or a CERT secure coding standard rather than writing one from scratch, and record which standards apply to which parts of the codebase.
2. Plan security in before, during, and after coding. Before coding, capture the security requirements for the feature and the flaw classes it needs to defend against. During coding, apply the standards and use security features of the language and framework instead of hand-rolling them. After coding, confirm through review and scanning that the standards were met. A.8.28 asks for secure practice across all three stages rather than only a scan at the end.
3. Use vetted components and manage dependencies. Pull third-party libraries from trusted sources, pin versions, and track what the codebase depends on. Software composition analysis (SCA) tooling, such as Dependabot or Snyk, flags known-vulnerable dependencies, and a maintained dependency inventory means a newly disclosed vulnerability can be traced to the code that uses it.
4. Run static analysis and secret scanning in the pipeline. Wire SAST into CI (for example, CodeQL or Semgrep) to catch flaw classes in the code, and secret detection to catch credentials committed to the repository. The rule that matters is that a failing scan blocks the merge, so an insecure change cannot reach production unreviewed; a scan that merely runs enforces nothing.
5. Review code for security as well as correctness. A second person reviews each change with security in scope: the reviewer checks that the coding standards were applied and that the change does not introduce a known flaw class, in addition to confirming the feature works. On a pipeline this is a required pull request approval where security is part of the review checklist.
6. Train developers on secure coding. Developers apply the standards only if they know them. Provide secure coding training for the languages in use and refresh it as the standards and threat landscape change, so the team recognizes the flaw classes the standards defend against.
7. Maintain a secure baseline and keep the rules current. Keep the coding standards, the scanner rule sets, and the approved-component list under version control and review them on a set cadence. A standard written once and never revisited stops matching the code, so the maintenance is part of the control rather than an afterthought.

The tooling behind these actions is a design decision rather than a fixed requirement. A team choosing pipeline security is weighing stitched-together open-source tools, source-control-native scanning, and an all-in-one platform, and the right fit depends on team size and developer capacity rather than on which product has the longest feature list. Legacy stacks complicate the scanners: when a codebase runs an older framework version that commercial SAST vendors no longer support, the answer is a lightweight scanner with rules for that framework rather than a framework migration that has nothing to do with security. A.8.28 asks that secure coding standards exist and are applied consistently; it does not require any particular vendor.

What evidence demonstrates A.8.28?

Auditors evaluating A.8.28 look for documented secure coding standards and evidence that development applied them across the audit period. Most of this evidence can be generated by the pipeline as a byproduct of normal work; wiring controls to produce their own evidence is the practice of GRC engineering.

How does A.8.28 map to SOC 2?

A.8.28 maps fully to SOC 2 CC8.1, the change management criterion that covers authorizing, developing, testing, approving, and implementing changes. A team with CC8.1 in place has already built the secure development practices A.8.28 asks for, and the same coding standard, scan results, reviews, and training records go into both audit packages. The SOC 2 to ISO 27001 control mapping covers the full crosswalk and what transfers between the two frameworks.

Related controls

A.8.28 sets the coding standards that the build stage applies; the controls around it govern the life cycle those standards operate inside and the testing that confirms them. A.8.25 (secure development life cycle) is the umbrella control that defines when secure coding applies across design, build, and release, and A.8.29 (security testing in development and acceptance) governs the testing gates that verify the code the standards produced. A.8.4 (access to source code) controls who can read and change the code the standards protect, and A.8.31 (separation of development, test and production environments) keeps the coding work out of production until it is reviewed. The technological controls overview summarizes how the A.8 controls fit together.

Frequently Asked Questions

What is ISO 27001 A.8.28?

ISO 27001 A.8.28, secure coding, is the Technological control in Annex A of ISO/IEC 27001:2022 that requires secure coding principles to be applied to software development. It covers adopting language-specific coding standards, planning security before and during coding, using vetted components, running static analysis and secret scanning, reviewing code for security, and training developers, so common flaw classes are handled consistently rather than left to individual habit.

What evidence satisfies A.8.28?

Typical A.8.28 evidence includes a documented secure coding standard, SAST and secret-scan results from the pipeline, software composition analysis or dependency reports, pull request review records that show security was in scope, and developer secure coding training records. Auditors look for both the written coding standards and evidence that development applied them across the period. The same artifacts satisfy SOC 2 CC8.1.

Is A.8.28 new in ISO 27001:2022?

Yes. Secure coding was introduced as its own control in the 2022 revision of ISO 27001. Earlier versions addressed secure development at the life cycle level, and the 2022 edition named secure coding separately to give the coding stage explicit weight. Teams recertifying from an older version should confirm they have documented coding standards and can show the standards are applied rather than only that a scanner runs.

How is A.8.28 different from A.8.25 secure development life cycle?

A.8.25 is the umbrella control that defines the whole secure development life cycle and when each security activity applies, from design through release. A.8.28 sets the specific secure coding standards developers follow during the build stage. A.8.28 is one of the activities that runs inside the life cycle A.8.25 establishes, and A.8.29 security testing governs the testing that verifies the code the standards produce.

Does A.8.28 require a specific SAST tool?

No. A.8.28 requires that secure coding standards are applied consistently; it does not mandate any particular scanner. A CI pipeline with SAST, secret detection, and software composition analysis is the most common way to enforce the standards, but a smaller team or a legacy stack can satisfy the control with lightweight or open-source scanners, provided the standards are documented, the scans run consistently, and a failing scan blocks a release.

How does A.8.28 map to SOC 2 CC8.1?

A.8.28 maps fully to SOC 2 CC8.1. Both require that changes be developed, tested, reviewed, and approved with security in scope before they reach production. A secure coding standard, SAST and secret-scan results, dependency reports, pull request reviews, and developer training records serve both frameworks without adaptation.