Policy Register
Every policy type · Operations and technology

Secure development policy

The rules for building and changing software: requirements, design, coding, testing, environments and the review before release.

How the register reads it

Also calledsecure SDLC, secure coding standard, application security policy
FamilyOperations and technology
Document typePolicy. The regimes ask for the content, not the label; a line pasted as a standard, procedure, plan or schedule is placed here with the label noted.
Expected ownerThe head of engineering or the CTO.
Review cadenceAnnual (the register's default: the clauses say planned intervals and on significant change, and do not fix a period).
On the gap list whenISO 27001 or NIS2 is ticked and no line resolves to it (ISO 27701 requires it too, inside a parent document, so it does not list it separately).
TemplateSecure development policy.

Which standards require it, and what each expects it to contain

5 requiring clauses, 3 regimes

Shown on a register for the regimes you tick; with none ticked, ISO 27001 is applied. Requirement text drawn from a human-verified compliance corpus under licence: the corpus statement of each clause, not the instrument verbatim.

ISO/IEC 27001:2022

ISO 27001 8.25 Secure development life cycle

Establish and apply rules for secure development of software and systems.

What the ISO 27002 guidance expects the document to say: Requires rules covering the secure development of both software and systems to be established and applied.

Evidence an auditor accepts: The secure development rules covering the full lifecycle, from requirements through design, build, test and release; evidence the rules apply to all development, including agile teams, integration work and vendor delivered code; evidence of security activities at each stage, such as threat modelling, secure design review, code review and security testing
Common gap: Policy exists but not enforced
Source: ISO/IEC 27001:2022; guidance ISO/IEC 27002:2022
ISO 27001 8.26 Application security requirements

Identify, specify and approve security requirements when developing or acquiring applications.

What the ISO 27002 guidance expects the document to say: Requires information security requirements to be identified, specified and approved when applications are being developed or acquired.

Evidence an auditor accepts: The method for identifying security requirements for applications, whether developed or acquired; documented and approved security requirements for applications delivered in the period, covering authentication, authorisation, data protection, logging and error handling; evidence requirements were derived from risk, from the data classification and from applicable legal obligations
Common gap: Security requirements not formally approved
Source: ISO/IEC 27001:2022; guidance ISO/IEC 27002:2022
ISO 27001 8.28 Secure coding

Apply secure coding principles to software development.

What the ISO 27002 guidance expects the document to say: Requires secure coding principles to be applied to software development.

Evidence an auditor accepts: The secure coding standard in use, per language and framework, and evidence it was communicated to developers; evidence of application, such as static analysis configuration and results, peer review records and the treatment of findings; evidence of control over third party and open source components, including inventory, known vulnerability checking and update process
Common gap: inconsistent application of coding standards
Source: ISO/IEC 27001:2022; guidance ISO/IEC 27002:2022

ISO/IEC 27701:2025

ISO 27701 A.3.27 Secure development life cycle

Policies for system development and design shall include guidance for the organization's processing of PII based on its obligations to PII principals, applicable legislation and regulation and the types of processing it performs, the Annex A controls providing the considerations; policies that contribute to privacy by design and privacy by default shall consider guidance on PII protection and the implementation of the ISO/IEC 29100 privacy principles in the development life cycle, privacy and PII protection requirements in the design phase drawn from privacy risk or impact assessment, PII protection checkpoints within project milestones, the privacy knowledge required, and minimising the processing of PII by default.

Evidence an auditor accepts: Development policy carrying the privacy by design and by default elements; privacy requirements captured at design from risk or impact assessment; privacy checkpoints in project milestones and evidence they are applied
Common gap: Privacy addressed at release through a legal review only
Source: ISO/IEC 27701:2025

The NIS2 Directive

NIS2 Art. 21(2)(e) Security in acquisition, development and maintenance, including vulnerability handling and disclosure

Two duties travel together in this point. The first is that security is built into how systems are acquired, developed and maintained: security requirements set before purchase or build, secure development practice, change control, and maintenance that does not quietly reintroduce weakness. The second is vulnerability handling and disclosure, meaning the entity can receive a vulnerability report about its own products or systems, triage it, fix it on a timescale that reflects severity, and handle disclosure. A published route for a finder to reach the entity is the part most often missing, and its absence is visible from outside. Note that the coordinator role and the European vulnerability database in Article 12 belong to the CSIRTs and ENISA; what binds the entity is its own handling and disclosure capability.

Evidence an auditor accepts: Security requirements applied in procurement and in the development lifecycle, with gate evidence; secure development practices in use, such as design review, code analysis and dependency scanning, with output; change and maintenance control records for in-scope systems
Common gap: Security requirements defined for new build only, leaving acquired and inherited systems untouched
Source: NIS2 Directive

Do this for every document on your list

Paste the list and get this reading for every document at once, with the owner and cadence against each, the clauses quoted, and the documents the regimes expect that the list does not carry. Eight documents free, no account.

Build a register

Physical security policy · Security testing and penetration testing policy