# 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*.

<!--
Guidance: How to use this template
- Use it when the organisation builds, configures or integrates software
  inside the ISMS scope: product code, internal tools, infrastructure as
  code, low-code automations and scripts that touch production data.
- Fill first: section 1 (scope, which code and which teams), section 4
  (the stages and gates you actually run) and section 15 (records). An
  auditor will sample a few recent changes and ask to see each gate.
- Main pitfall: writing a policy that describes an ideal pipeline nobody
  follows. Describe the gates that exist today, mark planned gates with a
  date, and record exceptions instead of pretending.
- This policy says WHAT must happen. The technical HOW lives in the
  Secure Coding Standard (`security/secure-coding-standard`) and the
  Software Supply Chain Security Assessment (`security/supply-chain-security`).
- Related templates: `isms/outsourced-development-security`,
  `isms/project-information-security-checklist`,
  `isms/secure-configuration-baseline`, `isms/data-masking-dlp-standard`,
  `ops/change-enablement-policy`, `security/threat-model`,
  `security/pentest-report`, `security/secrets-management-standard`,
  `ai-data/ai-usage-policy`, `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: Treat a change to a mandatory gate (section 4.2) or to the environment rules (section 10) as a major version that needs top management or CTO approval, because it changes what every team must do. -->

| 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] |

## Contents

- [1. Purpose and scope](#1-purpose-and-scope)
- [2. Policy statements](#2-policy-statements)
- [3. Roles and responsibilities](#3-roles-and-responsibilities)
- [4. Secure development life cycle](#4-secure-development-life-cycle)
- [5. Security requirements](#5-security-requirements)
- [6. Secure architecture and engineering principles](#6-secure-architecture-and-engineering-principles)
- [7. Secure coding](#7-secure-coding)
- [8. Security testing and acceptance](#8-security-testing-and-acceptance)
- [9. Outsourced development](#9-outsourced-development)
- [10. Separation of environments and test data](#10-separation-of-environments-and-test-data)
- [11. Change control and source code protection](#11-change-control-and-source-code-protection)
- [12. AI coding assistants](#12-ai-coding-assistants)
- [13. Software supply chain](#13-software-supply-chain)
- [14. Size tiers](#14-size-tiers)
- [15. Records and evidence](#15-records-and-evidence)
- [16. Compliance, exceptions and review](#16-compliance-exceptions-and-review)
- [17. References](#17-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: Say exactly which code is covered. Auditors often find "shadow" code (data pipelines, spreadsheets with macros, automation flows) that touches production data but sits outside the policy. Questions: which repositories, which teams, which platforms (low-code, infrastructure as code)? -->

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

<!-- Guidance: Keep each statement short, testable and owned. An auditor reads these and then asks "show me". If you cannot show it, either implement it or remove the statement and record a risk. -->

| 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

<!-- Guidance: Name roles, not people, and keep authorities explicit: who can approve a release with an open High finding? In small organisations one person holds several roles; then record the conflict guardrail (for example, no self-approval of merges). -->

| 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

<!-- Guidance: For A.8.25 an auditor wants to see that your teams follow a known way of working in which security has fixed checkpoints, not good intentions. Describe your real method (agile, continuous delivery, waterfall for regulated releases) and map gates onto it. The auditor will pick two or three changes and trace each gate to a record. -->

### 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.

```mermaid
flowchart LR
  A["1. Plan: risk class and requirements"] --> B["2. Design: threat model and architecture review"]
  B --> C["3. Build: secure coding, peer review, automated checks"]
  C --> D["4. Test: security testing and acceptance"]
  D --> E["5. Release: change approval and deployment"]
  E --> F["6. Operate: monitoring, vulnerability management"]
  F --> G["7. Retire: data deletion and decommissioning"]
  F -->|"new requirement or finding"| A
```

| 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

<!-- Guidance: A.8.26 matters because a security need nobody wrote down is never built or tested; this applies just as much to a product you buy as to one you code. Requirements must be testable. Questions: where are they recorded, who approves them, how are they traced to tests? Pitfall: "the system shall be secure" is not a requirement. -->

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

<!-- Guidance: For A.8.27, a short list of design rules that architects really check beats a long one nobody reads. List the few principles you really enforce, and how the architecture review checks them. Review them at least yearly and after major incidents. -->

| 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

<!-- Guidance: A.8.28 is new in 2022. Auditors ask three things: which rules apply, how developers learn them, and how they are enforced (review checklist, linters, static analysis). Keep the rules in the coding standard, not here. -->

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

<!-- Guidance: For A.8.29, testing should be part of the normal path to release, not an occasional event, and the go-live decision should look at its results. Define the testing depth per risk class and the release thresholds. Pitfall: an annual penetration test used as the only security testing. Auditors check that findings were fixed or formally accepted before release. -->

| 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

<!-- Guidance: A.8.30 applies when any part of development is done by a third party (agency, freelancer, offshore team, open-source maintainer paid by you). If nothing is outsourced, say so and keep the section with "not applicable" so the SoA justification has a source. -->

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

<!-- Guidance: A.8.31 exists because a mistake or a compromise in a test system should never reach live customers; A.8.33 exists because test copies of real data are a common source of leaks. Draw the real environments. Auditors check who has production access, whether developers can deploy directly, and whether a copy of production data sits in a test database. -->

### 10.1 Environments

```mermaid
flowchart LR
  DEV["Development: developers, synthetic data"] -->|"merge request"| CI["CI pipeline: build, test, sign"]
  CI --> TEST["Test or staging: masked or synthetic data"]
  TEST -->|"approved change"| PROD["Production: live data, restricted access"]
```

| 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

<!-- Guidance: A.8.32 is where unreviewed changes get caught before they break or weaken a system; A.8.4 is about who can see or alter the code and build tooling, since that is a direct route into production. Link to the operational change policy instead of repeating it. Auditors sample merges: do they have an independent approver? Is branch protection on? -->

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

<!-- Guidance: Many teams now use AI assistants for code completion, review and generation. State which tools are approved, what data may be sent to them and how output is checked. Align with the organisation's AI usage policy. If you run an AI management system, link ISO/IEC 42001 controls. -->

| 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

<!-- Guidance: A.5.21 covers ICT supply chain security and A.8.8 vulnerability management. For software, that means approved components, an SBOM, signed builds and monitoring of dependencies. Keep the detailed assessment in the supply chain template. -->

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

<!-- Guidance: Show the auditor that the policy fits the organisation. A 46-person company does not need a separate application security team, but it does need the gates. Use the shared fictional settings as patterns. -->

| 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

<!-- Guidance: A policy without records cannot be shown to operate. List what an auditor can sample, who keeps it and how long. Link each record type in the control evidence matrix (`isms/control-evidence-matrix`, DOC-ISMS-033). -->

| 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

<!-- Guidance: Say how compliance is checked (pipeline reports, internal audit sampling) and how exceptions are requested. Exceptions must be time-limited and owned. Review triggers keep the policy current between annual reviews. -->

- 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

<!-- Guidance: Cite only editions you checked. Re-check at every review: OWASP and NIST publish new versions. -->

| 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.