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

SDLC stages and gates, risk classes, security requirements, architecture, secure coding, testing, environments, test data, AI assistants, supply chain

ISMS und ISO/IEC 27001VollständigISO/IEC 27001:2022 A.8.25 to A.8.33 and A.8.4 (cited only); ISO/IEC 27002:2022secure development policyAktualisiert 01.11.2026

Im Editor öffnen.md herunterladen

Anleitung: Use it when your organisation builds or configures software inside the ISMS scope and needs one policy for the secure development life cycle. Fill the scope, the gates you actually run and the records section first. The main pitfall is describing an ideal pipeline nobody follows instead of the gates that exist today.

Vorschau

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

Field	Value
Document ID	DOC-ISMS-065
Version	[1.0]
Status	[Draft / In review / Approved / Superseded]
Owner	[@head-of-engineering]
Approvers/reviewers	[@cto], [@isms-manager], [@ciso]
Last updated	YYYY-MM-DD
Effective from	YYYY-MM-DD
Classification	[Internal]
Standard and edition	ISO/IEC 27001:2022 + Amd 1:2024 (A.8.4, A.8.25 to A.8.33); ISO/IEC 27002:2022
Next scheduled review	YYYY-MM-DD (12 months, or earlier on a trigger in section 16)
Applies to	[All engineering teams, platform team, data team, contractors and outsourced developers]
Supporting standards	Secure coding standard ([ID]); supply chain assessment ([ID]); DOC-ISMS-060 secure configuration baseline; DOC-ISMS-062 data masking and DLP standard

Approvals

Role	Name	Decision	Date
Policy owner	[@head-of-engineering]	[Prepared]	YYYY-MM-DD
ISMS manager	[@isms-manager]	[Reviewed]	YYYY-MM-DD
Top management	[@cto]	[Approved / Approved with changes]	YYYY-MM-DD

Revision history

Version	Date	Author	Change
0.1	YYYY-MM-DD	[@author]	First draft
1.0	YYYY-MM-DD	[@author]	Approved for issue
[x.y]	YYYY-MM-DD	[@author]	[Change summary]

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.

Item	Value
In scope	[Product source code, infrastructure as code, CI/CD pipeline definitions, database migrations, internal tools that process scoped data, low-code automations connected to production]
Teams	[Product engineering, platform, data, QA, contractors, outsourced development partners]
Platforms	[Repository host, CI/CD service, artifact registry, cloud accounts, low-code platform]
Out of scope	[Personal experiments that never touch company data or systems; purchased software used unchanged, covered by supplier management]
Related controls	A.8.25 secure development life cycle, A.8.26 application security requirements, A.8.27 secure architecture and engineering principles, A.8.28 secure coding, A.8.29 security testing in development and acceptance, A.8.30 outsourced development, A.8.31 separation of development, test and production, A.8.32 change management, A.8.33 test information, A.8.4 access to source code

2. Policy statements

ID	Statement	Control
SDP-POL-001	Every change to in-scope code passes the life cycle gates in section 4 before it reaches production.	A.8.25
SDP-POL-002	Security requirements are identified and recorded for every new system, significant feature and acquired component.	A.8.26
SDP-POL-003	Designs follow the approved engineering principles in section 6; deviations are recorded as design decisions.	A.8.27
SDP-POL-004	Code follows the Secure Coding Standard; reviews and automated checks enforce it.	A.8.28
SDP-POL-005	Security testing proportional to risk takes place before acceptance and release.	A.8.29
SDP-POL-006	Outsourced development meets the same rules through contract terms and acceptance checks.	A.8.30
SDP-POL-007	Development, test and production run in separate environments with their own access rules; production data is not used in lower environments unless masked or approved.	A.8.31, A.8.33
SDP-POL-008	Source code and build pipelines are access-controlled, logged and protected against tampering.	A.8.4
SDP-POL-009	Output from AI coding assistants is treated as untrusted code from an unknown author.	A.8.28
SDP-POL-010	Third-party components are approved, inventoried and monitored for vulnerabilities.	A.5.21, A.8.8

3. Roles and responsibilities

Role	Responsibilities
Policy owner (head of engineering)	Maintains this policy, reports compliance at the ISMS steering committee, approves gate changes
Security champion (one per team)	Runs threat modelling, triages scanner findings, first contact for security questions
Application security lead or ISMS manager	Sets testing depth, reviews High and Critical findings, assesses exception requests for the approver set in section 16
Developer	Follows the coding standard, writes tests, fixes findings in agreed timeframes, never bypasses gates
Reviewer	Reviews code for function and security, cannot approve their own change
Release manager or service owner	Confirms gates passed, authorises production release, owns rollback
Platform team	Operates repositories, pipelines, environments and secrets tooling securely
Procurement and legal	Puts section 9 requirements into contracts with development suppliers

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.

Stage	Security activities	Output record
1. Plan	Assign risk class, capture security and privacy requirements, check legal requirements in DOC-ISMS-014	Ticket with risk class and requirement links
2. Design	Threat model (`security/threat-model`) for class A and B, architecture review against section 6	Threat model, design decision record
3. Build	Coding standard, peer review, secret scanning, static analysis, dependency checks	Merge request with review and pipeline results
4. Test	Security test cases, dynamic testing, penetration test where required, acceptance by product owner	Test report, findings in the tracker
5. Release	Change approval per `ops/change-enablement-policy`, rollback plan, release notes	Change record, deployment log
6. Operate	Logging, monitoring, vulnerability remediation (DOC-ISMS-072)	Alerts, remediation tickets
7. Retire	Data deletion per `data/data-retention-deletion-standard`, credential revocation, archive of code	Decommissioning record

4.2 Mandatory gates

Gate ID	Gate	Pass criteria	Blocking?
SDP-GATE-01	Risk class assigned	Class recorded on the epic or ticket	Yes
SDP-GATE-02	Design review	Threat model approved for class A and B	Yes for A and B
SDP-GATE-03	Peer review	At least one independent approver; two for class A	Yes
SDP-GATE-04	Automated checks	No new Critical or High static analysis or dependency findings; no secrets detected	Yes
SDP-GATE-05	Security testing	Required tests in section 8 completed; open findings within thresholds	Yes
SDP-GATE-06	Release approval	Change record approved; rollback tested or justified	Yes

4.3 Risk classes

Class	Criteria	Examples (Example)
A (high)	Handles authentication, authorisation, payment, personal or regulated data at scale, cryptography, or exposes a new internet-facing interface	New login flow, tenant isolation change, export of customer data
B (medium)	Changes business logic on scoped data, adds an integration or a third-party component	New reporting feature, new webhook consumer
C (low)	No change to data flows, trust boundaries or privileges	Text change, styling, internal refactor with tests

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.

Source	Typical requirements
Risk assessment (DOC-ISMS-016)	Controls chosen to treat a specific risk
Classification (`data/data-classification-policy`)	Encryption, access restriction, logging for the data handled
Legal and contractual register (DOC-ISMS-014)	Retention, data residency, breach notification support, customer contract terms
Privacy	Data minimisation, purpose limitation, data subject request support (`compliance/privacy-by-design-review`)
Verification standard	Chosen level of OWASP ASVS 5.0.0 chapters for the application
Transaction services	Integrity of orders and payments, non-repudiation, replay protection

Requirement ID	Requirement	Source	Verified by
SDP-REQ-001 (Example)	Customer exports are generated only for users with the "export" permission in the same tenant	Risk RSK-014	Automated authorisation test, pentest case
SDP-REQ-002 (Example)	Export files are encrypted at rest and expire after 7 days	Classification: Confidential	Configuration test
SDP-REQ-003 (Example)	Every export is logged with user, tenant, time and row count	Customer contract clause	Log assertion test

6. Secure architecture and engineering principles

ID	Principle	How it is checked
SDP-ARC-01	Defence in depth: no single control protects a trust boundary	Architecture review checklist
SDP-ARC-02	Least privilege for users, services and pipelines	IAM policy review, `security/privileged-access-standard`
SDP-ARC-03	Secure by default: new features ship with the most restrictive setting	Design review
SDP-ARC-04	Zero trust between services: authenticate and authorise every call (`security/zero-trust-architecture`)	Service mesh or API gateway policy
SDP-ARC-05	Fail safe: errors deny access and do not leak internals	Code review, testing
SDP-ARC-06	Tenant isolation is enforced at the data layer, not only in the UI	Automated cross-tenant tests
SDP-ARC-07	Secrets are never stored in code or images (`security/secrets-management-standard`)	Secret scanning gate
SDP-ARC-08	Cryptography uses approved algorithms and libraries only (`security/cryptography-standard`)	Static analysis rules
SDP-ARC-09	Every component logs security events in the agreed format (`security/security-logging-standard`)	Log review in testing
SDP-ARC-10	Systems are designed for recovery: backups, infrastructure as code, documented restore	DR test (`ops/dr-test-report`)

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

Test	Class A	Class B	Class C
Unit and integration tests for security requirements	Required	Required	Where relevant
Static application security testing	Required	Required	Required
Software composition analysis	Required	Required	Required
Secret scanning	Required	Required	Required
Dynamic testing in the test environment	Required	Recommended	Not required
Infrastructure as code scanning	Required when infrastructure changes	Required when infrastructure changes	Required when infrastructure changes
Manual security review or penetration test (`security/pentest-report`)	Before first release and at least [annually]	Risk-based	Not required

Release thresholds:

Severity of open finding	Release allowed?	Fix timeframe (Example)
Critical	No	Before release
High	Only with an approved exception (section 16)	[14] days
Medium	Yes, ticket required	[60] days
Low	Yes	Next planned maintenance

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

Rule ID	Rule
SDP-ENV-01	Development, test and production run in separate accounts, subscriptions or projects with separate credentials.
SDP-ENV-02	Only the pipeline deploys to production; human deployment access is break-glass and logged.
SDP-ENV-03	Developers have no standing write access to production data; temporary access is approved and time-limited.
SDP-ENV-04	Development tools (compilers, debuggers, database consoles) are not installed on production hosts unless approved.
SDP-ENV-05	Environments are labelled clearly (names, banners, colours) to avoid acting on the wrong one.
SDP-ENV-06	Configuration of each environment follows DOC-ISMS-060.

10.2 Test data

Data option	When allowed	Approval
Synthetic data	Default for all environments	None
Masked or pseudonymised copy (DOC-ISMS-062)	Performance and migration testing where synthetic data is not realistic enough	Service owner
Unmasked production data	Exceptional, time-limited, with production-equivalent controls	Recorded exception approved at the DOC-ISMS-122 authority for the residual risk (data owner as risk owner); ISMS manager assesses

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:

Rule ID	Rule
SDP-SRC-01	Repositories are private by default; public repositories need approval from the head of engineering.
SDP-SRC-02	Default branches are protected: no direct pushes, required reviews, required status checks.
SDP-SRC-03	Write access is granted per team and reviewed at least [quarterly] (`ops/access-review`).
SDP-SRC-04	Commits to class A repositories are signed; build artifacts are signed and their provenance recorded.
SDP-SRC-05	Pipeline definitions are code, reviewed like code, and run with least-privilege credentials.
SDP-SRC-06	Repository audit logs are retained for [12] months and forwarded to the monitoring platform.
SDP-SRC-07	Emergency changes are reviewed retrospectively within [2] working days.

12. AI coding assistants

Rule ID	Rule
SDP-AI-01	Only tools on the approved list in `ai-data/ai-usage-policy` are used, under an organisational account with training on customer data disabled where the vendor offers that option.
SDP-AI-02	Secrets, credentials, personal data and customer data are never pasted into prompts.
SDP-AI-03	Generated code is reviewed by a human with the same rigour as any other code and passes every gate in section 4.2.
SDP-AI-04	Suggested dependencies are verified to exist and are approved under section 13 before use, to avoid invented or look-alike packages.
SDP-AI-05	Autonomous agents that can run commands or open merge requests work with least-privilege credentials in non-production environments.
SDP-AI-06	Code that calls a model at runtime follows the AI-specific rules in the coding standard and, where relevant, `ai-data/iso-27090-ai-security-review`.

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

Topic	Small: Quillmere Analytics Ltd (Example)	Medium: Quillmere Health Systems (Example)	Large: Quillmere Group (Example)
Profile	46 staff, one SaaS product, production on one public cloud in two regions	320 staff, clinical scheduling software and managed service	2,400 staff, 6 sites, IT and OT, many internal applications and supplier-built systems
Ownership	Head of Engineering Operations (also 0.5 FTE ISMS manager) owns the policy; CTO approves	Head of engineering owns it; 3-person security team runs application security	CISO's security office sets the group policy; each business unit appoints a development security lead
Gates	All six gates in the hosted CI service; one reviewer for class B and C, two for class A	All gates; release board for class A releases	Gates per platform; OT software follows vendor and plant change processes in addition
Testing	Static analysis, composition analysis and secret scanning on every merge; external pentest once a year	Adds dynamic testing in staging and pentest per major release	Central testing service, pentest programme by risk, OT testing in an isolated lab
Environments	Separate cloud accounts for dev, staging, production	Separate accounts plus a validation environment for hospital customers	Separate tenancies per business unit; OT engineering workstations segregated
Outsourcing	None; SoA records A.8.30 as not applicable with reason (some organisations keep it applicable with no current engagement; agree the approach with your auditor)	One agency builds the mobile app under DOC-ISMS-077	Several suppliers per site; supplier security agreement DOC-ISMS-068 for each
Separation of duties	Merge cannot be self-approved; CTO reviews production break-glass log monthly	Security team independent of product teams	Independent application security function and internal audit

15. Records and evidence

Record	Proves	Owner	Location	Retention (Example)
Tickets with risk class and security requirements	A.8.25, A.8.26	Product owner	[Issue tracker]	Life of the system + 2 years
Threat models and design decision records	A.8.27	Security champion	[Wiki or repository]	Life of the system
Merge requests with review approvals and pipeline results	A.8.28, A.8.4	Repository owner	[Repository host]	Life of the repository
Scanner results and findings tickets	A.8.29, A.8.8	Application security lead	[Scanner, tracker]	3 years
Penetration test reports and retest evidence	A.8.29	ISMS manager	[Document store]	3 years
Supplier contracts and acceptance test records	A.8.30	Procurement	[Contract repository]	Contract term + 6 years
Environment access lists and access reviews	A.8.31	Platform lead	[IAM, review records]	3 years
Test data log and approvals	A.8.33	Data owner	[Log]	3 years
Change and deployment records	A.8.32	Release manager	[Change tool, pipeline]	3 years
SBOMs per release	A.5.21	Platform lead	[Artifact registry]	Life of the release + 2 years
Training records for secure coding	A.8.28, 7.2	HR or ISMS manager	DOC-ISMS-026	Employment + 2 years
Exceptions	All	ISMS manager	DOC-ISMS-122 register	3 years after closure

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

Reference	Edition and status (checked 2026-11-01)	Use
ISO/IEC 27001:2022 + Amd 1:2024	Current; https://www.iso.org/standard/82875.html, Amd 1 https://www.iso.org/standard/88435.html	Annex A controls A.8.4, A.8.25 to A.8.33
ISO/IEC 27002:2022	Current; https://www.iso.org/standard/75652.html	Control guidance
ISO/IEC 27034-1:2011	Current; https://www.iso.org/standard/44378.html	Application security concepts
NIST SP 800-218, SSDF version 1.1	Final, February 2022, https://csrc.nist.gov/pubs/sp/800/218/final; SP 800-218 Rev. 1 (SSDF version 1.2) is a draft from December 2025: check whether it is final	Secure development practices
NIST SP 800-218A	Final, July 2024	SSDF community profile for generative AI and foundation models, useful for section 12
OWASP ASVS 5.0.0 and OWASP Top 10:2025	As cited in `security/secure-coding-standard`	Verification levels and risk categories

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.