Annex A 8.25: Secure Development Life Cycle

Annex A 8.25 expects a secure development life cycle (SDLC) that is intentional, repeatable, and evidenced. In practice, that means your engineering organization has defined security activities that occur at predictable points in the delivery flow, and those activities are enforced through process and tooling rather than personal heroics. The control is assessed as an operational capability: can you show that security requirements are considered before coding starts, that designs and code changes are reviewed, that security testing is performed, and that releases are controlled?

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate “secure SDLC” into concrete gates, clear ownership, and evidence capture. You do not need to rewrite engineering; you need to (1) set minimum security expectations for all software changes, (2) integrate them into existing systems (issue tracking, source control, CI/CD, artifact repositories), and (3) create a sampling-friendly evidence pack that a reviewer can validate quickly.

This page gives requirement-level implementation guidance for Annex A 8.25, focused on operationalizing the control and passing an ISO 27001 assessment with defensible, repeatable evidence. Sources: ISO/IEC 27001 overview; ISMS.online Annex A control index.

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 8.25 implementation expectation (Secure Development Life Cycle).” ¹

Operator interpretation: You are expected to implement a secure SDLC as a managed process. That means security is built into the development workflow, not handled only at the end. Your SDLC must be defined (documented), implemented (teams follow it), and verifiable (you can produce objective evidence for a sample of changes). ¹

Plain-English interpretation (what the control is really asking)

Annex A 8.25 is asking for three things:

1. A defined way of building software securely
   Document the minimum security steps your teams must follow when creating or changing software.

2. Security gates that actually run in the delivery process
   The process must be enforced through tooling, workflow rules, or release governance so it is not optional.

3. Evidence that your SDLC runs for normal work
   You need traceability from a change request to code, tests, scans, approvals, and release.

If your organization develops software, ships infrastructure-as-code, maintains internal scripts that touch production data, or configures SaaS in ways that change security posture, you should treat that work as “development” for Annex A 8.25 purposes.

Who it applies to (entity and operational context)

Applies to:

• Service organizations that design, develop, or materially modify software or software-like assets (applications, APIs, integrations, mobile apps, scripts, IaC, CI/CD pipelines). ¹

Operational contexts typically in scope:

• Product engineering and platform engineering
• DevOps/SRE when making infrastructure-as-code changes
• Data engineering when shipping pipeline code that handles sensitive data
• Security engineering when publishing detection/automation code that runs with elevated privileges
• Any team managing third-party code dependencies (open source packages, containers, libraries) that end up in your runtime environment

What you actually need to do (step-by-step)

Use this as a build sheet for operationalizing the annex a 8.25: secure development life cycle requirement.

1) Define SDLC scope and “what counts as a release”

• Write a short SDLC scope statement: which repos, services, and deployment paths are covered.
• Define release types: production releases, hotfixes, configuration changes, IaC changes, and emergency changes.
• Decide the minimum standard that applies to all changes vs. heightened steps for high-risk systems (authentication, payment flows, admin panels, systems processing regulated data).

Deliverable: Secure SDLC Standard (1–3 pages) + scope inventory aligned to how you deploy.

2) Establish security requirements at the start of work

• Add a security section to your engineering intake template (epic/user story): data classification, authN/authZ needs, logging requirements, third-party dependency impact.
• Require threat modeling (lightweight is fine) for defined triggers, such as new internet-facing endpoints, new sensitive data stores, or new privileged actions.

Evidence: Example completed intake tickets showing security fields filled in; threat model records for triggered work items.

3) Implement design and code review expectations

• Define required reviewers (peer review plus additional reviewers for high-risk components).
• Require documented security review criteria for pull requests: input validation, authZ checks, secret handling, error handling, logging, dependency changes.
• Enforce branch protections where feasible (no direct-to-main, required reviews, required checks).

Evidence: Repo settings screenshots/exports; pull request samples with reviews; documented code review checklist.

4) Build security testing into CI/CD

Minimum expectation for most environments:

• SAST or equivalent static checks
• Dependency/SCA scanning for open-source packages
• Secret scanning on commits and repos
• Container or artifact scanning if you ship images/packages
• A defined process to triage and fix findings, including who can accept risk and how exceptions expire

Evidence: CI job definitions; build logs showing scans run; sample scan reports; vulnerability tickets linked to remediation PRs.

5) Control releases and changes

• Make releases traceable to approved work items and tested builds.
• For emergency releases: define an emergency path with after-the-fact review, time-bound, and documented rationale.
• Ensure production access and deployment permissions align with your access control model (separation of duties where feasible).

Evidence: Release approvals; change records; deployment logs; emergency change post-review notes.

6) Manage third-party and open-source components as part of SDLC

• Define rules for introducing new dependencies: approved sources, license considerations, vulnerability scanning requirements.
• Require patching/upgrade workflow for critical findings, including ownership and prioritization.
• For third-party software development (outsourced dev): contractually require secure SDLC practices and request evidence (secure coding standards, testing outputs) as part of delivery acceptance.

Evidence: Dependency policy; sample dependency upgrade PRs; third-party SDLC clauses in SOWs/MSAs; third-party deliverable acceptance checklist.

7) Create a recurring evidence cadence (make audits easy)

• Pick a sampling approach you can repeat: “per release” evidence pack or “monthly sample” across products.
• For each sampled change, assemble a trace: ticket → PR → CI results → scans → approval → deployment.

Where Daydream fits naturally: Daydream can track Annex A 8.25 as a control with mapped activities and a recurring evidence request schedule so teams attach PR links, scan outputs, and approvals without rebuilding the workflow each audit cycle.

Required evidence and artifacts to retain

Keep artifacts in systems of record, and make them easy to export for an auditor sample.

Evidence type	What “good” looks like	Where it usually lives
Secure SDLC Standard	Versioned doc with gates, triggers, roles, and exceptions	GRC wiki / policy repo
Secure coding standard/checklist	Language/framework-specific guidance and review checklist	Engineering handbook
Threat modeling records	Trigger-based models tied to features	Ticketing system / docs
Pull request reviews	Required reviewers + security checks referenced	Git platform
CI/CD security checks	SAST/SCA/secret scan jobs visible in pipelines	CI system logs
Vulnerability management linkage	Findings result in tickets and remediations	VM tool + ticketing
Release/change approvals	Approvals, emergency path, trace to deployment	Change system / CI
Exceptions	Risk acceptance with approver and expiry	GRC workflow

Common exam/audit questions and hangups

Expect these during an ISO 27001 assessment:

• “Show me your secure SDLC procedure and how engineers know what to do.”
  Hangup: SDLC exists but is not adopted or is too abstract.

• “Pick two production releases and walk me end-to-end from requirement to deployment.”
  Hangup: No traceability from ticket to code to release.

• “How do you handle open-source dependencies and vulnerability findings?”
  Hangup: Scans run, but no triage workflow or documented risk acceptance.

• “What happens when you ship an emergency fix?”
  Hangup: Emergency changes bypass controls with no after-action review.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only SDLC
   Fix: tie requirements to tooling controls (branch protection, required checks) and show evidence for real changes.

2. One SDLC for everyone, regardless of risk
   Fix: define triggers for additional steps (threat model, security review) for higher-risk changes.

3. Scanning without governance
   Fix: document severity triage, ownership, risk acceptance authority, and exception expiry.

4. Ignoring “development” outside product engineering
   Fix: include IaC, scripts, data pipelines, and security automation in scope when they impact production.

5. Third-party code introduced without SDLC controls
   Fix: require the same intake, scanning, and approval controls for externally sourced components and outsourced development deliverables.

Enforcement context and risk implications

ISO 27001 is a certifiable standard rather than a regulator with direct civil penalty schedules. Your risk is still concrete: failure to meet Annex A 8.25 commonly results in audit nonconformities, customer assurance issues, and increased likelihood that software defects become security incidents. For service organizations, weak SDLC also turns into third-party risk exposure when customers require evidence of secure engineering practices. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Confirm SDLC scope: repos, services, deployment paths.
• Publish Secure SDLC Standard with minimum gates and exception flow.
• Identify toolchain coverage: Git, CI/CD, artifact registry, ticketing, scanning tools.
• Implement quick wins: PR review requirements and basic branch protections on in-scope repos.

Days 31–60 (enforce and prove operation)

• Add SDLC intake fields/templates in your ticketing system.
• Turn on or standardize SAST/SCA/secret scanning in CI for in-scope projects.
• Define vulnerability triage workflow and risk acceptance approvals.
• Run an internal audit-style sample: select recent changes and build evidence packs.

Days 61–90 (scale and make it sustainable)

• Expand to remaining repos and “shadow dev” areas (IaC, scripts).
• Add threat model triggers and lightweight templates; train tech leads on when to require it.
• Formalize third-party development intake and deliverable acceptance checks.
• Set a recurring evidence capture cadence in Daydream (or your GRC system) so you can produce samples on demand.

Frequently Asked Questions

Do we need a separate SDLC document if we already have engineering playbooks?

No, as long as the playbooks clearly define mandatory security gates, roles, and exceptions, and you can point an auditor to them and show they are followed for real releases.

What if we use agile and don’t have “requirements documents”?

Use your existing epics and stories as the requirement record. Add required security fields and threat model triggers so security is captured in the same workflow engineers already use.

Are infrastructure-as-code and configuration changes in scope?

If the change affects production security posture or availability, treat it as development for Annex A 8.25. Apply code review, testing, and controlled release expectations to IaC repos and automation scripts.

How do we handle exceptions when a scan blocks a release?

Define who can accept risk, what justification is required, and when the exception expires. Keep the exception tied to the specific release or artifact so it is auditable.

What evidence is most persuasive to auditors?

End-to-end traceability for sampled changes: ticket → pull request reviews → CI security checks → remediation tickets (if findings) → release/deployment approval. Screenshots help, but system-native exports and links are better.

Does Annex A 8.25 require specific tools like SAST or SCA?

The control expectation is a secure SDLC capability, not a named tool list. Tools help you enforce and evidence the process, but you can meet the requirement with equivalent controls if they are defined and verifiable. ¹

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview