Annex A 8.25 secure development life cycle: what auditors check

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 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 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.

Frequently asked questions