Secure development life cycle

Plain-language summary

Establishing and applying rules for building software and systems securely, from requirements through design, coding, testing and release, so security is designed in rather than bolted on — including scripts, low-code apps and anything others develop for you.

What the clause is really asking

Where an organisation builds software, this control asks for defined rules covering the whole development life cycle: security requirements at the start, secure design, secure coding standards, security checkpoints in the project plan, testing, protected source code and version control, separate environments, secure release, and developers who know the rules. Most 50–500-person organisations do not develop software, and it is legitimate to mark this control not applicable in the Statement of Applicability — with a written justification, not a blank. The trap is that the justification is often wrong. Auditors find PowerShell and Python scripts that run payroll exports, Power Apps and Power Automate flows built by a production planner, Excel workbooks with macros that drive quoting or batch calculations, a website maintained by an agency, ERP customisations by a partner. Each of those is development. Where they exist, the control applies in proportion: a short rule set for who may build, where code is stored, how it is reviewed and tested, and how changes reach production. Outsourced work is covered by 8.30 as well.

What auditors look for

Auditors first check the Statement of Applicability. If 8.25 is excluded, they test the justification: they ask IT and a few department heads about scripts, macros, Power Platform flows, website changes and ERP customisations, and they look inside the low-code environment if one exists. If the control applies, they ask for the secure development rules and trace one recent change or project from requirement through design, code review, testing and release, looking for the security checkpoints. They ask where source code is stored and who can change it. The hard question: who wrote the macro or script the business depends on most, and what happens when it breaks?

Typical evidence

Statement of Applicability entry with justification; secure development procedure or rule set; inventory of in-house scripts, macros and low-code apps with owners; version control or repository records; project records showing security checkpoints; code review and test records; developer and script-author training records; release and deployment records; outsourced development agreements.

How to comply — recommendations

Decide applicability on evidence: survey IT and department heads for scripts, macros, low-code apps, website work and ERP customisations, and record what you find. If none exist, write the justification in the SoA and revisit it at each management review. If some exist, write a two-page rule set proportionate to them: register every business-critical script, flow or macro with an owner; store code in a repository or controlled share with version history; have a second person review before production use; test with non-production data; send changes through change management. Use your low-code platform's environment and data-loss-prevention settings. Re-run the survey annually.

Common nonconformities

Control excluded from the SoA with no justification, or with a justification contradicted by scripts and low-code apps in use; no rules for in-house development; business-critical macros and scripts with a single author and no version control; no review or testing before code reaches production; low-code environment ungoverned; outsourced development with no security requirements.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.