ISO/IEC 27001:2022 · derived mapping target
A.8.25Secure development life cycle
Build security into the whole software development lifecycle, so protection is considered at every stage rather than tested for at the end.
Mapping at a glance
A.8.25Secure development life cycleISO/IEC 27001:2022
A.8.25 is covered by 21 Sekit CSF controls. +16 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0115Secure SDLC policy · PolicysupportsThis policy facet builds security requirements into each development stage, from design through release, for in-house and outsourced work, matching A.8.25's core lifecycle requirement.RCF-0116Secure SDLC policy · ProcesssupportsThe process facet runs the agreed security activities, requirements capture, code review, dependency checks, on every feature and release, not only the large ones.RCF-0117Secure SDLC policy · TechnicalsupportsThe technical facet configures the pipeline so automated security checks must pass before code reaches production, enforcing A.8.25's lifecycle discipline mechanically.RCF-0118Threat modeling · PolicysupportsThe threat-modeling policy facet requires threats to be documented before development starts on new applications and major changes, an early-lifecycle piece of A.8.25.RCF-0119Threat modeling · ProcesssupportsThe threat-modeling process facet runs a threat-identification session for each qualifying change and records what was found and decided.RCF-0120Threat modeling · TechnicalenablesTooling that captures identified threats in structured form and tracks each to closure gives A.8.25's threat-modeling step a durable record instead of a one-off workshop.RCF-0121Secure code review · PolicysupportsThis policy facet requires a security-focused review on every code change before release, one of the concrete practices A.8.25 expects.RCF-0122Secure code review · ProcesssupportsThe process facet runs a security-aware peer review, performed by trained developers, on every code change rather than a general functional review.RCF-0125SAST/DAST · ProcesssupportsThe process facet executes static and dynamic security tests as a routine part of every build and release, with findings triaged to closure.RCF-0126SAST/DAST · TechnicalsupportsThe technical facet integrates SAST and DAST tools into the pipeline so a critical finding automatically stops the release.RCF-0130CI/CD hardening · PolicysupportsThis policy facet sets written security requirements for the build and deployment pipeline itself, treating it as a production system A.8.25 must protect.RCF-0131CI/CD hardening · ProcesssupportsThe process facet applies and periodically re-verifies pipeline security controls on every build and deployment instead of configuring them once.RCF-0132CI/CD hardening · TechnicalsupportsThe technical facet locks down the pipeline so build definitions, secrets and deployment steps cannot be tampered with, enforcing a security gate at each stage.RCF-0133IaC scanning · PolicysupportsThis policy facet requires infrastructure-as-code templates to pass a security scan before deployment, extending A.8.25's lifecycle discipline to infrastructure definitions.RCF-0134IaC scanning · ProcesssupportsThe process facet scans every infrastructure template for misconfigurations as a routine step before changes are applied.RCF-0139Container security · PolicyrelatedThe container-security policy sets written standards for building and storing container images, a deployment concern beside rather than inside A.8.25's SDLC scope.RCF-0140Container security · ProcessrelatedThe process facet reviews container images and runtime configurations against the security standard on a recurring schedule.RCF-0143DevSecOps governance · ProcessenablesThis process facet makes security work a visible, recurring part of sprint planning, keeping A.8.25's security activities embedded rather than bolted on at the end.RCF-0365Privacy by design · ProcessrelatedThe privacy-by-design process runs a privacy check as a routine step before launch, a parallel discipline to A.8.25's security-by-design requirement rather than the same one.RCF-0366Privacy by design · TechnicalrelatedSystems default to the privacy-protective option, minimal fields, retention limits, opt-in sharing, a design-time control that complements A.8.25's secure-development focus.RCF-0403Release management · PolicysupportsThis policy facet defines how software updates are packaged, approved and released, including who authorizes a release, the release-gate piece of A.8.25's lifecycle.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
ISO/IEC 42001:2023 — Annex A counterparts
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Secure development policy
The rules the development team follows to build software securely: security requirements, code review and threat modeling.
Application security testing evidence
The proof that code and applications are automatically scanned for flaws (SAST/DAST), including dependencies and APIs.
CI/CD pipeline security
The security controls in the automated build-and-deploy process, including containers and infrastructure-as-code.
From the Sekit evidence catalog
In practice
Most SME development teams have a secure development policy on paper, but the lifecycle stops being secure the moment a deadline gets tight. SAST scanning runs on every pull request, yet a critical finding gets marked accepted risk in a chat thread instead of a tracked exception. Threat modeling happened once, when the product was first designed, and never again as new features shipped. Code review checks that the feature works, not that input is validated or secrets are not hardcoded. The gap auditors flag most often is the missing link between a scan finding and proof someone fixed it.
Common gaps
A secure development policy exists, but code reviews rarely include a security checklist, so common flaws slip through peer review unnoticed.
SAST scanning runs in the pipeline, but critical findings are silenced or waived rather than blocking the release.
Threat modeling happened for the initial system design and never again, so major feature changes ship without a fresh review.
Questions your auditor will ask
Does security review happen once at launch or throughout the lifecycle?
At every stage: threat modeling before development starts, security-aware peer review on each code change, and automated testing gating every release.
What stops a critical vulnerability from reaching production?
The build pipeline is configured so SAST and DAST findings marked critical automatically block the release until they are fixed.
Are infrastructure and container definitions treated as code that needs security review?
Yes, infrastructure-as-code templates and container images are scanned for misconfigurations before deployment, alongside the application code.
Who is accountable for authorizing a production release?
The release management policy names the approver and the packaging and approval steps every release must pass through.
Where regulation demands it
NIS2 Article 21 requires a secure development life cycle (6.2) with dedicated security testing at each stage (6.5).
ENS mp.sw.1 requires that application development follow a secure engineering discipline, from design through acceptance.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.8.25?”
Also via MCP, free with account