--- title: "Annex A 8.25 secure development life cycle: what auditors check" canonical: https://www.grcmana.io/vault/iso-27001/annex-a-8-25-secure-development-life-cycle published: 2023-07-31 updated: 2026-10-07 author: "Harry West" framework: "ISO 27001" control: "A.8.25 Secure development life cycle" journeyStage: implementation --- # Annex A 8.25 secure development life cycle: what auditors check ## Key takeaways Annex A 8.25 asks for written secure development rules that are applied across design, build, test, release and outsourced work. A continuous-delivery team meets it by encoding one short policy as branch protections, required reviews and scan thresholds that fail builds. Auditors trace one release end to end and check who can reach production. - **Control scope** — Annex A 8.25 requires written rules for secure development across design, coding, testing, release and outsourced work, applied and followed throughout the lifecycle rather than added at release. - **Method fit** — The control asks for rules, not phases, so continuous-delivery teams meet it through branch protection, required reviews and pipeline scan thresholds that fail builds, inside the workflow they already run. - **Audit sample** — Auditors trace one recent release from design record through review approvals, scan results, sign-off and deployment trail, then inspect the production access list to test environment separation. - **Finding grades** — No established development rules, or unrestricted routine production access, grades major. A skipped gate, missing training record or stale policy grades minor, aggregating to major where rules exist only on paper. The due-diligence questionnaire asks how security enters your software lifecycle. Your answer is a policy nobody on the team has reopened since the last audit, and the deal is waiting. This guide covers ISO 27001 Annex A 8.25 secure development life cycle for engineering teams of 25 to 250 people. It shows how to turn one short policy into branch protections, peer review and scan thresholds that fail the build. Your pipeline then enforces the rules and records the evidence, and you will see what auditors check when they sample a release. ## What does ISO 27001 Annex A 8.25 require? ISO 27001:2022 Annex A 8.25 secure development life cycle requires written rules for building secure software and systems. The rules apply across the whole lifecycle: design, coding, testing, release and any outsourced work. The control asks that the rules exist and are followed, not that teams adopt phases, so a continuous-delivery team can meet it. The reasoning is practical. The [NCSC Software Security Code of Practice implementation guidance](https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance/theme-1-secure-design-development) warns that when a secure development framework is not followed throughout the life cycle, security gets bolted on at the end. The result is delay and extra cost. The rules you write should cover seven areas: - **Design:** security considered when features are specified, including inside project management. - **Engineering and coding:** engineering principles and secure coding standards applied as the code is written. - **Testing:** checks that probe for weaknesses before release. - **Repositories:** code and configuration held in protected repositories under disciplined version control. - **People:** developers trained to find and fix flaws. - **Licences:** obligations attached to third-party code handled. - **Environments:** production kept apart from where development happens. That list looks long until you notice how much is ordinary engineering hygiene. Git, CI and cloud accounts already exist in most teams this size. The standard cares that your rules exist and operate, not that they are heavy. Outsourced work sits inside the same scope. An agency writing your mobile app is part of your lifecycle, whatever its contract says about liability. ## Why is Annex A 8.25 secure development life cycle the umbrella for the other development controls? Annex A 8.25 is the umbrella control. The neighbouring development controls supply detail on coding, testing and environment separation, while A.8.25 requires the rules to exist and be followed. Auditors treat it as the anchor, so a missing rule set here usually produces findings against the downstream controls too. Each neighbouring control supplies the detail for one part of the lifecycle: - A.5.8 puts information security into project management. - A.8.27 sets secure system architecture and engineering principles. - A.8.28 covers secure coding. - A.8.29 covers security testing in development and acceptance. - A.8.31 separates development, test and production environments. The commercial stake is just as direct. For a regulated buyer, your development process is part of your product. That is why the questionnaire probes whether scanning gates your releases and how you keep developers out of production, and why thin answers stall procurement. The engineering economics point the same way. A flaw caught at design costs a conversation. The same flaw in production costs an emergency release, possibly a breach notification, and sometimes a customer. ## How do you build an ISO 27001 SDLC for a continuous-delivery team? Write one short secure development policy, then encode it where engineers already work. Branch protection, pipeline scans, a security line in the design-doc template and a named release sign-off turn the policy into daily practice. The security actions sit inside the existing iterative workflow rather than forming a separate lifecycle. The [OWASP Developer Guide on secure development and integration](https://devguide.owasp.org/en/02-foundations/02-secure-development/) makes the same point from the engineering side. A secure SDLC is the development lifecycle you already run, with security actions built into each phase. For a team of around 50 people, the path runs in four steps: 1. **Write one policy.** A few pages cover A.8.25 and the controls A.8.26 to A.8.31. Say how security enters design, which coding standards apply, what testing gates a release, how environments are separated and how repositories are protected. One document, not seven. 2. **Encode the rules in tools.** Require a second reviewer through branch protection. Run static analysis on your code and dependency checking on everyone else's in CI, with thresholds that fail the build. Add a security line to the design-doc template and a release checklist with a named sign-off. 3. **Add lightweight threat modelling.** For significant features, spend thirty minutes at design time asking "how would someone abuse this?" and record the answer in the ticket. Skip the enterprise tooling, because the discipline is the point. 4. **Train for your stack.** Teach the flaws that matter in your stack, using the OWASP Top 10 as the standard reference. A short annual session plus a secure code-review culture beats a generic e-learning module. The commonest failure is a policy written for a process the team never adopted. The document describes waterfall-style gates, the team ships continuously, and the auditor reads the gap as a management system that is not operating. A secure development policy describing a process the team doesn't run is evidence against you. The opposite mistake is over-engineering. A six-person team has no need for an enterprise SDLC framework with stage-gate committees. Checklists, pipeline gates and peer review are the proportionate version, and they leave velocity intact. ## How do you keep developers out of production? Separate cloud accounts or projects for development, test and live, deploy only through the pipeline, and treat break-glass access as logged and exceptional. Manual deployment "because we're small" is the finding written most often at this scale, and a pipeline is the cheapest fix. Four arrangements make separation real: - **Separate accounts or projects.** Development, test and live each get their own, with no credentials shared between them. - **Pipeline-only deployment.** Production credentials belong to the pipeline's service identity, not to individual engineers. - **Narrow human access.** People hold the read access they need for diagnosis, granted through groups rather than one-off grants. - **Logged break-glass.** Emergency write access is requested against a ticket, time-limited and reviewed afterwards. Break-glass is the part teams skip, and it is what makes the rest credible. Production will break at 2am, and someone will need to act. A logged, reviewed exception shows the rule survives contact with an incident. If a developer can deploy by hand, the pipeline is a suggestion. The "we're small" reasoning runs backwards. A small team's pipeline is simple, so adding a deployment job is a configuration task rather than a project. Once no one can deploy by hand, separation becomes a property of the platform instead of a promise in a policy. ## How do you manage open-source dependencies and contractors under Annex A 8.25? Keep an inventory of third-party components with automated alerts when one turns vulnerable, and check licence terms fit commercial use. For outsourced development, the rules travel by contract: your standards named as binding, acceptance testing before delivery, and audit rights you can exercise. Start with the code you did not write. Dependency checking in CI feeds the inventory, and each alert needs a named owner who triages it. Licence surprises are legal debt, and vulnerable dependencies are the modern breach vector. A licence check in the same CI job can flag terms that do not fit commercial use, so the question is settled at the merge request rather than during a buyer's due diligence. For contractors, the same rules apply to their code as to yours. The contract is where you make that enforceable: - **Binding standards.** Your secure development rules are named in the contract as obligations, not offered as guidance. - **Acceptance testing.** Delivery is accepted only after your own checks pass, and the contract says so. - **Audit rights.** You hold the right to verify practice, and you are ready to use it. - **Selection evidence.** A supplier that cannot evidence secure practice before signing has told you something about the engagement. The blind spot is the agency whose code ships under your name. If the contract carries no security obligations and nobody runs acceptance testing, your rules stop at the edge of your payroll. The code still enters production. Assurance, not assumption, is the standard to hold. ## What do auditors inspect for the ISO 27001 Annex A secure development life cycle? Auditors pick a recent release and trace it end to end: design record, review approvals, scan results, sign-off and deployment trail. They then check who can touch production. No established development rules, or unrestricted routine production access, grades major; a skipped gate or stale policy grades minor. Expect questions like these in the room: - Where would a new engineer read your development rules? - Walk me through your last release, from design to production. - What stops a developer pushing straight to live? - Where does security testing happen in the pipeline, and what fails a build? - Your mobile app is built by an agency. How do your rules reach them? The access check is deliberate: the auditor reads the access list, not the policy. For outsourced work, the contract is pulled and checked for security obligations. The evidence set that answers those questions: - The secure development policy, with version history showing it is maintained. - Pipeline configuration showing the scanning stages and their fail thresholds. Auditors increasingly ask to see the live CI screen rather than a screenshot. - Merge-request records showing the second-reviewer rule operating, and one release with its security sign-off. - Environment evidence: the account or project separation, who holds production access, and a deployment trail showing releases flow through the pipeline. - Threat-modelling notes or design-doc security sections for a recent feature, and penetration test reports where performed. - Developer training records and the dependency inventory. - Outsourced-development contracts carrying your security clauses and acceptance criteria. ### How findings grade Our grading guidance follows a consistent pattern. Absence or total breakdown of the control grades major: no established rules, or developers with unrestricted routine production access. Isolated lapses grade minor: a release that skipped a gate, a missing training record, a stale policy. Minors aggregate to a major where the trail shows the rules exist only on paper. A live CI screen and a permalinked release answer most of these questions directly. The audit becomes a walkthrough rather than a document hunt. ## How does Annex A 8.25 relate to change management (A.8.32) and legacy A.14 questionnaires? Annex A 8.25 governs how software is engineered, from design through coding and testing. A.8.32 governs how a finished change is authorised and lands in production. The pipeline usually implements both, but auditors test them separately. Questionnaires still citing the 2013 secure development policy control, A.14.2.1, are answered by pointing to this 2022 control and its evidence. In practice, one pipeline produces two evidence sets. For A.8.25, you show the review rules, the scan thresholds and the testing that gates a release. For A.8.32, you show who authorised the change and how it reached production. Keep the two trails separate so each control can be sampled on its own. When a customer questionnaire cites A.14, handle it in three moves: 1. **Answer the question asked.** Name ISO 27001:2022 Annex A 8.25 and the control title, then describe how your pipeline operates it. 2. **Attach evidence.** Offer the policy, a pipeline configuration export and one merge-request record. 3. **Avoid improvised mappings.** The rest of the old A.14 spreads across several 2022 controls, including A.8.26, A.8.29 and A.8.32. If the customer wants a formal crosswalk, use the correspondence table in ISO/IEC 27002:2022 rather than a third-party summary. ## How does GRC engineering turn the secure development life cycle into self-evidencing infrastructure? Branch protection, required reviews and scan thresholds are repository and pipeline settings, so the platform enforces the control and the configuration export is the evidence. Every merge request and deployment then carries its own trail. When the auditor asks to see a release, you send a permalink rather than start an archaeology project. The development lifecycle is the easiest part of Annex A to automate, because the toolchain is already software. Two further mechanisms close the loop: - **Separation asserted continuously.** Scheduled checks reconcile production-access lists against the allowed set and flag console deployments that bypassed the pipeline. - **Dependency risk as a live feed.** Component inventories update on every build. A newly published vulnerability in something you ship raises a ticket automatically, which ties this control into technical vulnerability management (A.8.8). Set the threshold before the first scan runs. A workable starting rule fails the build on new critical findings and routes lower severities to a ticket queue with an owner. Without that decision, findings pile up in a dashboard nobody triages. A scanner that can't fail a build is a dashboard, not a control. At this scale, the payoff is straightforward. Engineers keep shipping, the platform keeps the records, and the evidence for the next audit is already sitting in the repositories. | Mechanism | What it enforces | Cadence | Evidence it leaves | | --- | --- | --- | --- | | Branch protection and required review | No merge without a second reviewer | Every merge request | Merge-request records and protection settings export | | Scan thresholds in CI | Builds fail above the agreed severity | Every build | Pipeline configuration and build logs | | Pipeline-only deployment | Releases reach production only through the pipeline | Every deployment | Deployment trail per release | | Separation check | Flags console deployments and unexpected production access | Scheduled run | Reconciliation output against the allowed list | | Dependency feed | Raises a ticket when a shipped component turns vulnerable | Every build and each new advisory | Component inventory and ticket history | ## Frequently asked questions ### Does A.8.25 apply if our developers only write internal scripts, low-code workflows or AI pipelines? Proportionately, yes. Automation scripts, low-code workflows and AI/ML pipelines are software, and they can hold credentials and touch production data. Version control, review and secrets hygiene apply in a lighter form. List where such code runs and what it can reach, then give the ones holding production credentials the pipeline treatment first. ### Do we need expensive security tooling to meet Annex A 8.25? No. Free-tier static analysis and dependency scanning, platform-native branch protection and a written release checklist satisfy the control at this scale. Choose tools that run inside the CI you already use, so evidence appears without extra work. Spend on tooling when scale demands it, not for the certificate. ### How long does Annex A 8.25 take to implement for a team on modern tooling? Policy plus pipeline wiring takes two to three weeks for a team already on Git, CI and cloud environments. Most of the machinery exists, so the work is configuring it deliberately and writing down what is now true. Evidence accumulates from the day the gates switch on, so start this control early in your certification project, alongside A.8.27. A team with no CI pipeline yet should build that first. ### Does A.8.25 require penetration testing? Not as a fixed requirement, in our view. A.8.25 asks that your rules say what testing gates a release, and A.8.29 carries the testing detail. A penetration test report is supporting evidence where you have one, read alongside pipeline scan results and review records. A customer contract that demands an annual test is a commercial requirement, separate from what certification needs.