ISO 27001 A.8.25: Secure Development Life Cycle

To satisfy ISO 27001 A.8.25, write down the rules that govern how your team builds software, then apply them consistently across the whole life cycle: threat modelling and security requirements at design, secure coding standards during build, automated security gates in the pipeline (SAST, dependency and secret scanning), separate environments, code review, and a security sign-off before release. The action teams most often get flagged on is running the security gates without a documented rule that says they are required, so a passing pipeline exists but nothing states that a failing scan blocks a release.

A.8.25 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.25?

ISO 27001 A.8.25, titled Secure development life cycle, requires an organization to establish and apply rules for the secure development of software and systems. The intent, as expressed in ISO/IEC 27001:2022, Annex A, is that security is built into every stage of how software is designed, written, tested, and released, rather than inspected in at the end or left to individual judgement.

A.8.25 is the umbrella control for secure development. It does not prescribe a methodology, a language, or a toolchain. What it expects is that the organization has defined how security applies from requirements through to release, and that development follows those rules in practice. A.8.25 sets the frame; the specific development controls operate inside it. Secure coding standards (A.8.28), security testing (A.8.29), and environment separation (A.8.31) are the parts; A.8.25 is the documented life cycle that ties them together and says when each applies.

How do you implement A.8.25?

Establish a written secure development life cycle, then wire its rules into how the team already builds and ships. Because A.8.25 governs the development process rather than any single host, the actions are the same whether the application runs in the cloud or on-prem. Run this sequence:

1. Define secure development rules. Document the life cycle: what security activities happen at each stage, who owns them, and what blocks a release. This is the artifact A.8.25 asks for by name. It does not need to be long, but it needs to state the rules a developer and an auditor can both point to.
2. Set security requirements and threat model early. Before code is written, capture the security and privacy requirements for the feature and identify how it could be attacked. Threat modelling at design is cheaper than finding the same flaw in production, and it produces a record that security was considered upstream.
3. Apply secure coding standards. Adopt a coding standard for the languages and frameworks in use, so that common flaw classes (injection, broken access control, unsafe deserialization) are handled the same way by everyone. This is where A.8.28 secure coding operates inside the life cycle.
4. Enforce security gates in the pipeline. Wire automated checks into CI so that every change is scanned before it can merge: static application security testing (SAST) for code flaws (for example, CodeQL or Semgrep), software composition analysis (SCA) for vulnerable dependencies (such as Dependabot or Snyk), and secret detection to catch credentials committed to the repository. The rule that matters is that a failing gate blocks the merge; a scan that merely runs enforces nothing.
5. Separate development, test, and production environments. Build and test changes somewhere other than production, so an unreviewed change cannot reach live data or customers. This is A.8.31 operating as part of the life cycle.
6. Require code review. A second person reviews each change before it merges. On a pipeline this is a required pull request approval; the reviewer and the author are not the same person.
7. Require a security sign-off before release. A defined approval gate confirms that the security activities ran and passed before a change ships. The passing gates, the review, and the approval together are the release record.

CI/CD pipelines make most of these actions mechanical: branch protection blocks a merge until required status checks (SAST, SCA, secret detection) pass and a second reviewer approves, and the deploy log records what shipped. The tooling is a design decision rather than a fixed requirement. A team evaluating pipeline security is choosing between 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. Weighing structural choices like these is the kind of work a security architecture review covers. Legacy applications complicate the gates: 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.25 asks that the gates exist and run consistently; it does not require any particular vendor.

What evidence demonstrates A.8.25?

Auditors evaluating A.8.25 look for the documented secure development life cycle and evidence that development followed it across the audit period. Most of these artifacts can come straight out of the pipeline; treating evidence collection as an engineering problem is the core of GRC engineering.

How does A.8.25 map to SOC 2?

A.8.25 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 life cycle A.8.25 asks for, and the same policy, pipeline scan results, reviews, and release approvals 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.25 is the life cycle umbrella; the controls around it are the specific activities that run inside it. A.8.28 (secure coding) sets the coding standards the build stage applies, and A.8.29 (security testing in development and acceptance) governs the testing gates the pipeline enforces. A.8.31 (separation of development, test and production environments) gives the life cycle the non-production environments it builds and tests in, and A.8.32 (change management) governs how an approved change moves to production. A.8.4 (access to source code) controls who can read and change the code the life cycle protects. The technological controls overview summarizes how the A.8 controls fit together.

Frequently Asked Questions

What is ISO 27001 A.8.25?

ISO 27001 A.8.25, secure development life cycle, is the Technological control in Annex A of ISO/IEC 27001:2022 that requires an organization to establish and apply rules for the secure development of software and systems. It covers security across the whole life cycle: requirements and threat modelling at design, secure coding, security testing gates, environment separation, code review, and a security sign-off before release.

What evidence satisfies A.8.25?

Typical A.8.25 evidence includes a documented secure development policy or SDLC standard, CI security-gate results from SAST, dependency scanning, and secret detection, pull request review records, threat models or security requirements for significant features, and release sign-offs. Auditors look for both the written rules and evidence that development followed them across the period. The same artifacts satisfy SOC 2 CC8.1.

How is A.8.25 different from A.8.28 and A.8.29?

A.8.25 is the umbrella control that defines the secure development life cycle and when each security activity applies. A.8.28 secure coding sets the specific coding standards developers follow during the build stage. A.8.29 security testing governs the testing performed in development and acceptance. A.8.28 and A.8.29 are activities that run inside the life cycle A.8.25 establishes.

Does A.8.25 require a CI/CD pipeline?

No. A.8.25 requires that security rules apply consistently across development; it does not mandate any particular tooling. A CI/CD pipeline with automated SAST, dependency scanning, and secret detection is the most common way to enforce the gates, but a smaller team or a legacy stack can satisfy the control with lightweight or open-source tools, provided the scans run consistently and a documented rule states that a failing gate blocks a release.

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

A.8.25 maps fully to SOC 2 CC8.1. Both require that changes be developed, tested, reviewed, approved, and documented before they reach production. A secure development policy, CI security-gate results, pull request reviews, test-environment separation, and release approvals serve both frameworks without adaptation.

Do cloud and on-prem teams implement A.8.25 differently?

The secure development life cycle rules, gates, reviews, and sign-offs are the same regardless of where the application runs, because A.8.25 governs the development process rather than the host. The pipeline tooling and the scanners may differ by team size and stack, and legacy frameworks can require lighter-weight or open-source scanners, but the life cycle rules and the evidence they produce stay the same.