ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
An ISO 27001 secure development policy is the document most software companies write once, file, and never look at again — and it is the document a stage 2 auditor will pull apart line by line, because it has to carry ten Annex A controls rather than the one its name suggests. ISO/IEC 27001:2022 contains 93 controls in four themes (37 organizational, 8 people, 14 physical, 34 technological), and ten of the technological controls sit in the development family: A.8.25 through A.8.34.
The mismatch is historical. In ISO/IEC 27001:2013 there genuinely was a control called “Secure development policy” — A.14.2.1. In the 2022 edition it was renamed and rescoped as A.8.25 Secure development life cycle, and the work it used to describe was redistributed. So the phrase everybody still searches for no longer names a control, and a policy written against the 2013 title will come up short against the 2022 Statement of Applicability.
This guide sets out what the ten controls require, which 2013 documents you can reuse, where the family most often fails an audit, and how to map the result onto the free NIST Secure Software Development Framework. Work through it in that order and your ISO 27001 secure development policy ends up shorter, not longer. Figures and dates were verified in October 2026.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
Build an ISO 27001 secure development policy from the control text rather than from a template. A.8.25 requires that rules for the secure development of software and systems be established and applied. That second verb is the one that fails: a signed policy with no evidence of application is a finding, not a pass. The same pattern runs through the rest of the family — each control pairs a definition requirement with an operational one.
Note also what is not required. A secure development policy is not on the list of documents ISO/IEC 27001:2022 mandates by name; our ISO 27001 mandatory documents checklist runs to seven documents plus six categories of records, and this is not among them. But excluding the development controls in the Statement of Applicability is unrealistic for any organization that ships code, and the SoA itself is mandatory under clause 6.1.3. In practice the policy is optional in form and compulsory in substance.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
Two structural changes in the 2022 edition explain most of the confusion around the ISO 27001 secure development policy.
First, 2013’s A.14 “System acquisition, development and maintenance” was dismantled. Its thirteen controls were redistributed across the 2022 Annex A, and two controls that had nothing to do with development in the first place — operational change management (A.12.1.2) and the separation of development, test and operational environments (A.12.1.4) — were pulled into the development family.
Second, and the point almost no competing guide makes: 2013’s A.14.1.1, “Information security requirements analysis and specification”, did not stay in the development family at all. It maps to A.5.8 Information security in project management, an organizational control. That means the requirements-gathering half of secure development is now evidenced through your project governance, not your SDLC. A policy that starts at “design” leaves A.5.8 unevidenced, and an auditor who follows the mapping will notice.
The table below gives the 2022 control, its 2013 origin, and the artefact that usually satisfies it. Where a 2013 control is listed, you already have a document to reuse.
| 2022 control | Title | 2013 origin | Primary evidence |
|---|---|---|---|
| A.8.25 | Secure development life cycle | A.14.2.1 | The policy itself, plus SDLC stage gates |
| A.8.26 | Application security requirements | A.14.1.2, A.14.1.3 | Requirements baseline per application; transaction controls |
| A.8.27 | Secure system architecture and engineering principles | A.14.2.5 | Design principles document; architecture review records |
| A.8.28 | Secure coding | New in 2022 | Coding standard, SAST configuration, dependency policy |
| A.8.29 | Security testing in development and acceptance | A.14.2.8, A.14.2.9 | Test plans, scan results, acceptance criteria |
| A.8.30 | Outsourced development | A.14.2.7 | Supplier contract clauses; right-to-audit; code ownership |
| A.8.31 | Separation of development, test and production environments | A.12.1.4, A.14.2.6 | Environment inventory; promotion pipeline; access split |
| A.8.32 | Change management | A.12.1.2, A.14.2.2, A.14.2.3, A.14.2.4 | One change record set covering code and infrastructure |
| A.8.33 | Test information | A.14.3.1 | Test data standard; masking or synthetic data evidence |
| A.8.34 | Protection of information systems during audit testing | A.12.7.1 | Agreed scope and timing for scans and audit tooling |
Nine of the ten have a 2013 ancestor. One does not.
ISO/IEC 27001:2022 added eleven controls that had no 2013 predecessor: threat intelligence, information security for use of cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering and secure coding. Only the last of those lands in the development family.
The practical consequence for an organization that transitioned from the 2013 edition — the transition window closed on 31 October 2025 — is predictable. Nine development controls inherited a document. A.8.28 inherited nothing. If your SoA shows the whole family as implemented but your evidence folder has no coding standard, no static analysis configuration and no rule on third-party components, that is where the nonconformity will be raised.
A workable A.8.28 position inside an ISO 27001 secure development policy has three parts: a minimum secure coding baseline that applies to code you write and to components you pull in; tooling that enforces it in the pipeline rather than at review time; and a decision rule for accepting external libraries. The same “defined and implemented” pairing we described for the ISO 27001 cryptography policy applies here — the written baseline is the easy half.
A.8.32 is the single most under-scoped control in the family, and it is a merge of four 2013 controls: system change control procedures (A.14.2.2), technical review of applications after operating platform changes (A.14.2.3), restrictions on changes to software packages (A.14.2.4) and — critically — operational change management (A.12.1.2).
That last one is what breaks dev-only change processes. Under the 2022 edition, one control covers your deployment pipeline and the firewall rule someone changed at 2am, the database parameter tweak, and the platform upgrade that nobody classified as a change. If your ISO 27001 secure development policy describes pull requests and releases but your infrastructure changes live in a separate ticket queue with different approval rules, you have two processes answering to one control and no single population an auditor can sample.
The fix is not to merge the tools. It is to write one change policy with one classification scheme, one approval matrix and one record format, then let the pipeline and the operations queue both feed it. Keep the logging and monitoring evidence aligned to the same change identifiers so a sampled change can be traced end to end.
A single 40-page ISO 27001 secure development policy satisfies the auditor and nobody else. The split below keeps the policy short enough to approve annually and pushes the volatile detail into documents engineers actually read.
| Document | Controls it carries | Owner | Review cadence |
|---|---|---|---|
| Secure development policy | A.8.25, A.8.27, A.8.30 | CTO or head of engineering | Annual, plus on major SDLC change |
| Secure coding standard | A.8.28 | Engineering leads | On language or framework change |
| Application security requirements baseline | A.8.26 | Product plus security | Per application, at design |
| Security testing standard | A.8.29, A.8.34 | Security engineering | Annual |
| Change management policy | A.8.32 | Platform or operations | Annual |
| Environment and test data standard | A.8.31, A.8.33 | Platform engineering | Annual |
Record the split in the Statement of Applicability so each control points at a named document. Our guide to the ISO 27001 Statement of Applicability covers how to phrase the justification column when one document covers several controls.
An ISO 27001 secure development policy tells you what to control; it does not tell you how to build software. The free framework that does is NIST’s Secure Software Development Framework. SP 800-218, SSDF Version 1.1, published February 2022, is still the current final edition — 19 practices across four groups.
Worth knowing before you restructure anything: NIST released the initial public draft of SP 800-218r1 (SSDF Version 1.2) on 17 December 2025, with comments closing 30 January 2026. As of October 2026 it remains an initial public draft; the final was originally expected by the end of March 2026 and has not appeared. The draft adds two practices — PO.6, for improvement over time, and PS.4, for robust and reliable software updates. Map to 1.1 today, and treat 1.2 as a signal of where the update-integrity conversation is going rather than something to implement.
| SSDF practice group | What it covers | Annex A controls it supports |
|---|---|---|
| Prepare the Organization (PO) | People, process and tooling readiness; the documented SDLC | A.8.25, A.8.27 |
| Protect the Software (PS) | Integrity of code, repositories and the build environment | A.8.31, A.8.32 |
| Produce Well-Secured Software (PW) | Secure design, code review, static and dynamic analysis | A.8.26, A.8.28, A.8.29, A.8.33 |
| Respond to Vulnerabilities (RV) | Finding, fixing and learning from vulnerabilities | A.8.8, A.8.29 |
If you outsource development, the same mapping gives you contract language for A.8.30: require the supplier to evidence specific SSDF practices rather than asking for a generic security attestation.
This is the question every engineering team now asks, and the honest answer is that ISO/IEC 27001:2022 does not address it directly. ISO/IEC 27002:2022 remains the current guidance edition, and the only amendment to ISO/IEC 27001:2022 is Amendment 1:2024, which concerns climate action — not artificial intelligence. Vendor pages claiming A.8.28 “now requires” oversight of AI coding assistants are offering interpretation, not standard text.
What follows from the controls as written is still fairly clear. A.8.28’s secure coding baseline applies to code regardless of who or what produced it, and A.8.26’s requirements baseline does not change because a model drafted the implementation. Treat an AI coding assistant as a tool whose output enters your repository, decide in the risk assessment whether that warrants additional review, and write the decision down. For organizations that build AI systems rather than merely code with assistance, NIST published SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models, on 26 July 2024 as a companion profile to the SSDF.
If you sell software or connected products into the EU, secure development has stopped being purely a certification matter.
| Obligation | Instrument | Status |
|---|---|---|
| Report actively exploited vulnerabilities and severe incidents | EU Cyber Resilience Act, Article 14 | In force since 11 September 2026 |
| Essential cybersecurity requirements, vulnerability handling, conformity assessment | EU Cyber Resilience Act, Annex I | Applies from 11 December 2027 |
| ISO/IEC 27001:2013 certificates | Transition to the 2022 edition | Closed 31 October 2025 |
The Article 14 reporting duty is live now; the design and vulnerability-handling requirements follow in December 2027. Our guide to the EU Cyber Resilience Act sets out the product classes and conformity routes. The useful point for an ISMS is that the CRA’s vulnerability-handling expectations and A.8.29’s testing requirements want the same evidence, so build them once.
Expect the audit to work from a sample rather than from the text of your ISO 27001 secure development policy. Have these to hand:
Primary source for the control text and amendment status is the standard itself at iso.org, which lists ISO/IEC 27001:2022 as edition 3 with one amendment. The SSDF is free from NIST.
No. ISO/IEC 27001:2022 does not name it in the documented information it requires. But A.8.25 requires rules that are established and applied, and excluding the development controls in the Statement of Applicability is not credible for an organization that writes software, so in practice you need the document.
Sometimes, and the exclusion must be justified in the SoA rather than simply omitted from your ISO 27001 secure development policy. If you configure SaaS rather than develop, A.8.25 to A.8.30 and A.8.33 may be genuinely inapplicable — but A.8.31 and A.8.32 usually are not, because you still move configuration between environments and still make changes. Exclude control by control, never the family.
Typically eight to fifteen pages for the policy itself, with the coding standard, testing standard and change policy as separate documents. Length is not the measure; an auditor samples application, so a shorter policy you can prove you follow beats a comprehensive one you cannot.
No. The control requires secure coding principles to be applied; it names no product or technique. Static analysis is the common way to show enforcement at scale, but code review with recorded outcomes can satisfy it for a small codebase. What fails is a baseline with no mechanism behind it.
The evidence overlaps heavily — change management, environment separation and testing are tested under both. The difference is in form: ISO 27001 is a certification against a management system standard, while SOC 2 is an attestation report produced by a CPA firm. One well-built change process serves both.
Our ISO 27001 Toolkit provides 165 templates mapped to ISO/IEC 27001:2022, including the secure development policy, secure coding standard, change management policy, test data standard and the Statement of Applicability that ties them to A.8.25 through A.8.34. It is $99 as a one-time purchase, with no subscription and no per-user fee. If you would rather see how the controls fit together first, start with our breakdown of the 93 ISO 27001 Annex A controls.
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026