APP-001 Secure Development Lifecycle Policy
Description
A documented secure software development lifecycle policy exists, defining the security activities required at each phase: requirements, design, development, testing, deployment and maintenance. Security requirements are defined before development begins. The policy names the development standards the work is held to and the tools used at each phase, and records the configured options for each of those tools. Changes to the standards, the tools or their configured options carry a recorded approval. The policy, the standards and the tool configurations are reviewed at least annually against the security and privacy requirements they are meant to satisfy.
Rationale
Security introduced late in the lifecycle is expensive and incomplete, and a formal policy keeps it in view from inception. A pipeline that runs a static analysis tool with every rule class disabled satisfies an unqualified requirement to run one, so the policy becomes testable only once the tools and their configured options are written down. Reviewing those configurations against the requirements, and not only the policy text, catches a tool that has quietly stopped covering what it was chosen for.
Applicability (9 profiles)
Applies to the deployer's own development, including the integrations, prompts and agents it builds on procured models. The provider's lifecycle for the product is evidenced through AIG-032.
Applies to the deployer's own development, including the integrations, prompts and agents it builds on procured models. The provider's lifecycle for the product is evidenced through AIG-032.
Framework Mappings (12)
| AIS-01 | Application and Interface Security Policy and Procedures | full |
| AIS-04 | Secure Application Development Lifecycle | full |
| AIS-12 | Source Code Management | informative |
| AIS-01 | Application and Interface Security Policy and Procedures | full |
| AIS-04 | Secure Application Development Lifecycle | full |
| 8.25 | Secure development life cycle | full |
| 8.30 | Outsourced development | partial |
| NIS2-Art.21.2.e | Security in Acquisition, Development and Maintenance | partial |
| NIS2-CIR-6.2 | Secure Development Life Cycle | partial |
| SA-1 | Policy and Procedures | partial |
| SA-15 | Development Process, Standards, and Tools | full |
| SA-3 | System Development Life Cycle | full |
Evidence (3)
Documented SDLC policy defining security activities required at each development phase, with the policy owner, effective date, and review cadence.
Example: Secure SDLC Policy document (PDF or Confluence page) with sections mapping to requirements, design, development, testing, deployment, and maintenance phases, showing the security gate or activity required at each phase. Document must show a named approver and an effective or last-reviewed date within the last 12 months.
Test: Request the SDLC policy document. Verify: (1) all six phases (requirements, design, development, testing, deployment, maintenance) have at least one defined security activity, (2) the document identifies a named owner, (3) the last-reviewed or next-review date is within 12 months, (4) the policy is communicated to the engineering team, evidenced by a distribution record, onboarding checklist, or training record.
Annual review record confirming the SDLC policy was reviewed, updated if needed, and re-approved within the last 12 months.
Example: Jira review ticket, Confluence page version history, or document management system audit trail showing the SDLC policy was reviewed and approved by the named owner within the last 12 months, with any changes noted.
Test: Request the SDLC policy version history or review ticket. Verify: (1) a review was completed within the last 12 months, (2) the reviewer holds an appropriate role (e.g. Head of Engineering, CISO), (3) if changes were made, the updated policy was re-approved and communicated to affected staff.
Development standards and tooling register naming the standards the work is held to, the tools used at each lifecycle phase and the configured options for each, with a version and a date.
Example: Engineering standards and tooling register v2.3, 2026-05-30
Test: Request the standards and tooling register. Verify: (1) every phase the policy names has at least one named standard or tool against it, (2) the recorded options for the static analysis and dependency scanning tools match the options actually set in the pipeline configuration, (3) the register's last review falls within the policy's review interval and the review compared the configurations against the security and privacy requirements, (4) a change to a tool or a standard during the period carries a recorded approval, (5) a tool listed in the register is still in use, checked against recent pipeline runs.
Questions (3)
Does your organisation have a documented secure software development lifecycle (SDLC) policy that defines required security activities at each development phase?
The policy must cover all phases: requirements, design, development, testing, deployment, and maintenance. It should have a named owner, effective date, and defined review cadence.
How frequently is the secure SDLC policy reviewed and updated?
Annual review is the minimum. The policy should be updated whenever there is a significant change in development technology, tooling, or regulatory requirements.
Which of the following does your secure development lifecycle documentation record?
Options run from the most commonly documented to the least. Tool configurations are the element most often left out, and they are where a requirement quietly stops being met: a scanner running with its rule classes disabled still satisfies an unqualified requirement to run a scanner. Name capabilities rather than products in the register itself.