Secure Development Policy Template (ISO/IEC 27001 A.8.25 to A.8.31)

Secure Development Policy: [Organization name]

Sets the rules that every software and system change inside the ISMS scope follows, from the first requirement to the retirement of the system: life cycle stages and security gates, security requirements, architecture principles, secure coding, security testing, separation of environments, test data, change control, outsourced work, AI coding assistants and the software supply chain. Supports ISO/IEC 27001:2022

• Amd 1:2024 Annex A controls A.8.25 to A.8.31 (A.8.28 secure coding is new in the 2022 edition), with A.8.4, A.8.32 and A.8.33, guided by ISO/IEC 27002:2022. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

• 1. Purpose and scope
• 2. Policy statements
• 3. Roles and responsibilities
• 4. Secure development life cycle
• 5. Security requirements
• 6. Secure architecture and engineering principles
• 7. Secure coding
• 8. Security testing and acceptance
• 9. Outsourced development
• 10. Separation of environments and test data
• 11. Change control and source code protection
• 12. AI coding assistants
• 13. Software supply chain
• 14. Size tiers
• 15. Records and evidence
• 16. Compliance, exceptions and review
• 17. References
• Standard and licence note

1. Purpose and scope

Fixing a security flaw after release costs far more than avoiding it on the whiteboard. This policy puts security checks at each stage of how our teams plan, build, ship and retire software, so that releases do not add avoidable weaknesses to the services inside the ISMS scope defined in DOC-ISMS-002.

2. Policy statements

3. Roles and responsibilities

Roles and RACI for the wider ISMS are in DOC-ISMS-006.

4. Secure development life cycle

4.1 Stages

The life cycle applies to every work item; the depth of each activity scales with the risk class in section 4.3.

4.2 Mandatory gates

4.3 Risk classes

5. Security requirements

Security requirements are written for every class A and B item and for every acquired application, and are traced to at least one test.

6. Secure architecture and engineering principles

7. Secure coding

Developers apply the Secure Coding Standard (security/secure-coding-standard), which covers input validation, output encoding, authentication, session management, access control, cryptography, secrets, error handling, dependencies, file handling and APIs, mapped to the OWASP Top 10:2025 categories and OWASP ASVS 5.0.0.

Minimum expectations:

• New developers complete secure coding training within [30] days of joining and before merge rights to class A repositories; refresher every [12] months (records in DOC-ISMS-026).
• Every merge request uses the review checklist with security items.
• Static analysis, secret scanning and dependency checks run on every merge request; findings above the threshold block the merge.
• Language-specific rules, banned functions and approved libraries are kept in the coding standard annex and reviewed at least yearly.
• Code that is copied from public sources is reviewed like new code and its licence is checked before use.

8. Security testing and acceptance

Release thresholds:

Acceptance testing confirms that security requirements are met before the product owner accepts a release. Acquired systems receive acceptance testing against their requirements before go-live. Audit and assurance testing on production systems (including penetration tests) is planned and agreed with the system owner so it does not disrupt operations (A.8.34).

9. Outsourced development

Development performed by third parties follows this policy through the requirements in Outsourced Development Security Requirements (DOC-ISMS-077, isms/outsourced-development-security). In summary:

• contracts carry the secure development obligations, IP and licence terms, right to audit and testing evidence requirements;
• suppliers work in accounts and repositories controlled by [Organization name], with named accounts and MFA;
• all supplier code passes the same gates in section 4.2, and acceptance testing is performed by [Organization name], not only by the supplier;
• access is removed at the end of the engagement and the offboarding is recorded.

10. Separation of environments and test data

10.1 Environments

10.2 Test data

Test data that contains personal or confidential information is deleted when the test ends, and its use is logged. Copies to test are recorded in [the test data log].

11. Change control and source code protection

Changes follow ops/change-enablement-policy and use change records per ops/change-request where the policy requires them. For source code:

12. AI coding assistants

13. Software supply chain

Third-party and open-source components are managed per the Software Supply Chain Security Assessment (security/supply-chain-security):

• new direct dependencies are checked for maintenance activity, licence and known vulnerabilities before adoption;
• a software bill of materials is generated for every release of class A and B systems and kept with the release record;
• dependency versions are pinned and updates arrive through reviewed merge requests;
• vulnerabilities in components are triaged and fixed within the timeframes in security/vulnerability-management-policy;
• the build system is hardened and its outputs signed, with provenance recorded where the platform supports it.

Organisations that publish an SSDF conformance statement record it in security/ssdf-practice-attestation (NIST SP 800-218, SSDF version 1.1).

14. Size tiers

15. Records and evidence

Recommended measures for DOC-ISMS-080 (Example): percentage of merges with an independent approver (target 100%), median days to fix High findings (target under 14), percentage of class A releases with a current threat model (target 100%).

16. Compliance, exceptions and review

• Compliance is monitored through pipeline reports and sampled by the internal audit programme (DOC-ISMS-082).
• Exceptions to any gate or rule are requested through security/security-exception-request (DOC-ISMS-122) and approved at the authority the risk methodology (DOC-ISMS-010 section 2.4) sets for the residual risk: the risk owner for Low; the risk owner and department head for Medium (top management if the risk category is Averse, DOC-ISMS-015 section 9 rule 1); top management with a treatment decision for High, recorded in the risk acceptance record (DOC-ISMS-019). Critical residual risk is not approvable as an exception: treat it or stop the activity. The ISMS manager or application security lead assesses each request. Gate exceptions are limited to [90] days, within the DOC-ISMS-122 maximum (12 months for Low or Medium, 6 months for High); at expiry they are reassessed, and they are recorded in the risk register where the residual risk is Medium or higher.
• Deliberate bypass of a gate is a security breach handled under DOC-ISMS-052.
• The policy is reviewed every [12] months and after: a major incident caused by a software defect, a new development platform or language, a new outsourcing arrangement, or a change of the coding standard or OWASP references.

17. References

Related templates: security/secure-coding-standard, security/supply-chain-security, isms/outsourced-development-security, isms/project-information-security-checklist, security/threat-model, security/pentest-report, ops/change-enablement-policy, compliance/statement-of-applicability, isms/control-evidence-matrix.

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 Annex A controls A.8.4 and A.8.25 to A.8.33 and with ISO/IEC 27002:2022. The text, gates, rules and examples are original. Control numbers are cited with short descriptive labels; no text from ISO/IEC 27001, ISO/IEC 27002 or ISO/IEC 27034-1 is reproduced, and you need the official standards to implement the controls. NIST SP 800-218 is a US government work. Check the current editions before use. Template licence: MIT.