ISO 27001 A.8.25: Secure Development Life Cycle

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 8.25 requires that rules for the secure development of software and systems be established and applied, embedding security across the entire development life cycle rather than bolting it on at the end.

The Bottom Line: A.8.25 is the umbrella control for building software securely. It ties together architecture (8.27), requirements (8.26), coding (8.28), testing (8.29) and environment separation (8.31) into one disciplined life cycle. Security designed in is exponentially cheaper than vulnerabilities found in production.

What the Control Asks For

The ISO 27001:2022 Text

In short:

ISO 27001:2022 Annex A 8.25 asks organizations to establish and apply rules for securely developing software and systems.

Do you need this control?

A.8.25 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if you develop or significantly customise software or systems. Organisations that only buy software can exclude it with that reason and rely on A.5.20, A.5.21 and A.8.26.

What ISO 27002:2022 Adds

ISO/IEC 27002:2022 (8.25), paraphrased: secure development is needed to build a secure service, architecture, software and system. Consider:

• (a) separating development, test and production environments (8.31);
• (b) guidance on security in the development life cycle: security in the development methodology (8.28, 8.27) and secure coding guidelines for each programming language used (8.28);
• (c) security requirements in the specification and design phase (5.8);
• (d) security checkpoints in projects (5.8);
• (e) system and security testing, such as regression testing, code scanning and penetration tests (8.29);
• (f) secure repositories for source code and configuration (8.4, 8.9);
• (g) security in version control (8.32);
• (h) the application security knowledge and training people need (8.28);
• (i) developers' ability to prevent, find and fix vulnerabilities (8.28);
• (j) licensing requirements, and alternatives that avoid future licensing problems (5.32).

Where development is outsourced, get assurance that the supplier follows your secure-development rules (8.30). 27002 also notes that development happens inside applications too: office applications (macros, spreadsheets), scripts, browsers and databases.

The "shall vs should" Analysis

What Auditors Actually Check

1. Documented secure-development rules/standard (an SSDLC).
2. Security in requirements and design (link 8.26) and secure coding guidelines (8.28).
3. Security testing: SAST/SCA/DAST and pen tests (8.29), performed and acted on.
4. Separated dev/test/prod (8.31) and secure source repositories (8.4).
5. Developer security training (8.28/8.25 (h)).

Why a Secure Development Life Cycle Matters

The Business Risk Narrative

Software you build is software you are responsible for securing. Vulnerabilities introduced in design or coding, injection flaws, broken authentication, exposed secrets, vulnerable dependencies, become the breaches of tomorrow. The economics are stark: a flaw caught in design costs a fraction of the same flaw exploited in production. A secure development life cycle bakes security into every phase so vulnerabilities are prevented or caught early, rather than discovered by an attacker.

How It Goes Wrong (hypothetical patterns)

• Security only at the end. A manual test a week before release finds an authentication flaw that needs a redesign; the release ships anyway with the risk "accepted".
• Unscanned dependency. A library with a known critical vulnerability is pulled in and nobody notices until a customer's scanner reports it.
• Secret in the repository. A cloud access key is committed to a public repository and abused within hours.
• Production data in test. A test environment with real customer records is exposed through a forgotten debug endpoint.
• Ungoverned spreadsheet macro. A finance macro that moves payment files is changed without review and sends payments to the wrong account.

Indian Regulatory Context

• DPDP Act 2023: section 8(5) requires reasonable security safeguards. Secure development is how you build them into systems that process personal data.
• RBI: the Master Direction on Digital Payment Security Controls (2021) sets application security life cycle expectations for digital payment products (it applies to banks, small finance banks, payments banks and credit-card-issuing NBFCs; fintechs working with them usually inherit it through contracts), and the Master Direction on IT Governance, Risk, Controls and Assurance Practices (2023) covers IT and application risk for regulated entities.
• SEBI: the Cybersecurity and Cyber Resilience Framework (CSCRF, 2024) covers application security, including secure development and testing, for regulated entities.
• IRDAI: the Information and Cyber Security Guidelines (2023) apply to insurers and intermediaries.
• CERT-In: the Technical Guidelines on Software Bill of Materials (first issued October 2024) set out how to produce and share SBOMs. BFSI and government buyers increasingly ask suppliers for them.
• Customer due diligence: enterprise customers and SOC 2 reviews ask Indian SaaS and IT vendors for evidence of an SSDLC and application security testing.

Industry-Specific Consequences

Impact of Non-Compliance

Application vulnerabilities are among the most exploited breach vectors, and the cost of fixing them post-incident, plus breach response, regulatory penalties, and customer loss, dwarfs the cost of an SSDLC. For software-producing organisations, A.8.25 is foundational both to security and to commercial credibility.

Scope and Applicability

What the Control Covers

• The rules and practices for securely developing software and systems in-house and via outsourced/sub-contracted development, across methodology, requirements, design, coding, testing, environments, repositories, version control, and developer competence.

Who It Applies To

Any organisation that develops or significantly customises software/systems (including low-code, scripts, and integrations). Pure software consumers focus on acquisition (5.20/5.21/8.26); developers implement the full SSDLC.

Development inside applications. 27002 reminds you that spreadsheets with macros, Power Apps or similar low-code tools, browser extensions and database stored procedures are development too. Indian finance teams often run critical processes on macros. Keep a register of business-critical spreadsheets and macros, control who can change them, review changes, and keep versions.

Size-Based Applicability

Key Definitions and Terminology

Relationship to Other Controls

The Umbrella of the A.8.25–8.31 Family

A.8.25 is the integrating control for application security. ISO 27002's guidance is essentially a map to its sibling controls: requirements (8.26), architecture (8.27), coding (8.28), testing (8.29), outsourced development (8.30), and environment separation (8.31). Implementing 8.25 means orchestrating those controls into one coherent, evidenced life cycle, which is exactly what an auditor wants to see.

Security Across the SDLC Phases

Security checkpoints (27002 (d)) at phase boundaries ensure no project proceeds carrying unmanaged security debt.

DevSecOps and Security Testing (SAST/DAST/SCA)

Modern secure development integrates security into CI/CD ("shift left, automate"):

Security gates block the pipeline on defined criteria (e.g. no critical SAST/SCA findings). Tune to avoid alert fatigue: fail on high-confidence criticals, triage the rest. Maintain AppSec champions in dev teams to scale the culture.

Detailed Implementation Guidance

Establish the Secure-Development Rules (SSDLC)

Document an SSDLC standard covering the items in 27002 (a)–(j): environments, methodology and coding guidelines, security requirements, checkpoints, testing, repositories, version control, training, developer capability, and licensing. Align to a recognised framework (NIST SSDF, OWASP SAMM).

Build Security Into Requirements and Design

Capture security/privacy requirements (8.26) and perform threat modelling at design; insert security checkpoints at phase gates (27002 (c), (d)).

Apply Secure Coding and Manage Components

Adopt secure coding guidelines per language (8.28); manage open-source/third-party components with SCA and licensing checks (link 5.21, 5.32); vault secrets, never hardcode.

Automate Security Testing (8.29)

Embed SAST, SCA, secret scanning in CI; add DAST/IAST and penetration testing before release; act on findings via vulnerability management (8.8).

Separate Environments and Secure Repositories

Keep dev/test/prod separate (8.31); secure source-code repositories and configuration with least-privilege access (8.4) and protected version control (8.32); no production data in dev/test (link 8.33).

Train Developers (27002 (h), (i))

Provide application-security training so developers can prevent, find and fix vulnerabilities; reinforce with secure-coding standards and champions.

Extend to Outsourced Development (8.30)

Where development is outsourced/sub-contracted, contractually require the same secure-development rules and obtain evidence (link 5.20, 8.30).

A Lightweight SSDLC for Startups

A small team can meet 27002 8.25 without heavy process:

Provide SBOMs to Customers

B2B customers, especially in BFSI and government, increasingly ask for a software bill of materials. Generate an SBOM (CycloneDX or SPDX) in the build, keep one per release, and agree how you will share it and how you will tell customers about vulnerable components. The CERT-In SBOM guidelines describe the expected content.

Secure Development Environment and Repositories

• Secure repositories (27002 (f)): least-privilege access to source code (link 8.4); branch protection; signed commits where warranted; secret scanning; no secrets in repos.
• Version control security (27002 (g)): protected branches, mandatory review, audit trail, controlled merges to release (link 8.32).
• Secure development environment: hardened developer endpoints/build infrastructure; protected CI/CD with least-privilege pipeline identities (link 5.16 non-human identity); signed build artefacts and build provenance (SLSA).
• Environment separation (27002 (a)): development, test and production strictly separated (8.31); no live personal/production data in non-prod (use masked/synthetic data, link 8.11/8.33).

Secure SDLC Policy (Template)

Illustrative extract (the Control Pack has the full policy):

Secure Development Life Cycle Policy — [Organisation Name] (A.8.25)

1. All software/systems shall be developed under the [Organisation] SSDLC, aligned to NIST SSDF /
   OWASP SAMM, covering methodology, requirements, design, coding, testing, release and
   maintenance.

2. Security and privacy requirements shall be defined at requirements stage (A.8.26); threat
   modelling and security checkpoints shall be performed at design and phase gates.

3. Secure coding guidelines (per language) shall be applied (A.8.28). Secrets shall not be
   hardcoded; third-party/open-source components shall be scanned (SCA) and licence-checked.

4. SAST, SCA and secret scanning shall run in CI; DAST and penetration testing shall be
   performed before major releases (A.8.29). Security gates block on critical findings.

5. Development, test and production environments shall be separated (A.8.31); production data
   shall not be used in non-production (use masked/synthetic data).

6. Source code repositories and version control shall be secured with least-privilege access,
   branch protection and audit trails (A.8.4, A.8.32).

7. Developers shall receive application-security training. Outsourced development shall meet
   these rules contractually (A.8.30).

8. Third-party and open-source components shall meet licensing requirements (A.5.32). An SBOM
   shall be produced for each release.

9. Business-critical spreadsheets, macros, low-code apps and database procedures are in scope
   and shall be registered, change-controlled and reviewed.

Risk Assessment and Treatment

Audit and Compliance Checklist

(The Control Pack's audit evidence checklist (04) lists where to find the evidence for each question.)

Metrics and KPIs

Common Pitfalls and Audit Failures

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1, Indian SaaS Company (Bengaluru, 800 staff): DevSecOps for Enterprise Trust

Challenge. A B2B SaaS vendor relied on manual, pre-release security testing that frequently slipped, shipped vulnerable dependencies, and had no documented SSDLC, repeatedly failing enterprise customers' security reviews and ISO 27001 expectations.

Solution (10 weeks).

1. Established an SSDLC aligned to NIST SSDF / OWASP SAMM with security requirements, threat modelling, and phase checkpoints.
2. Integrated SAST, SCA and secret scanning into CI with security gates on critical findings; added DAST and pre-release penetration testing (A.8.29).
3. Enforced environment separation (A.8.31) and masked test data (A.8.11/8.33); secured repositories and CI/CD pipeline identities.
4. Ran an AppSec training program and appointed security champions in each squad.

Results. Critical findings at release fell to 0; vulnerable-dependency density dropped sharply; enterprise security reviews began passing, and the SSDLC evidence became standard sales collateral, directly enabling larger deals.

Illustrative Scenario 2, Indian Bank Digital-Channels Team (Mumbai): Secure SDLC for Banking Apps

Challenge. The bank's digital-banking development lacked a formal secure SDLC; security was a late, manual gate, environments were loosely separated, and an RBI-aligned review flagged the absence of design-stage security and consistent application security testing.

Solution (14 weeks).

1. Implemented a secure SDLC with mandatory security requirements, threat modelling, and security checkpoints for all banking applications.
2. Built a DevSecOps pipeline (SAST/SCA/secret scanning + gates) and mandated pre-release penetration testing (A.8.29).
3. Enforced strict dev/test/prod separation (A.8.31) with no production data in non-prod, and secured source repositories/version control (A.8.4/8.32).
4. Delivered AppSec training and integrated findings into vulnerability management (A.8.8).

Results. Design- and code-stage security now standard; application vulnerabilities caught pre-release; the secure SDLC satisfied the RBI-aligned review and the ISO 27001 auditor, and reduced damaging late-stage rework.

16A. Advanced Implementation Guidance

Figure · Tiers

Maturity levels for secure development life cycle

16A.1 The DevSecOps Pipeline in Detail

Modern secure development integrates security gates into CI/CD so checks run automatically on every change. A reference pipeline: pre-commit, secret scanning, linting; on pull request: SAST (code flaws), SCA (vulnerable/licensed dependencies); on build: container/image scanning, IaC scanning, SBOM generation (link A.5.21); in test: DAST/IAST against a running build; pre-release: penetration testing for significant releases; at deploy: signed artefacts and environment separation (A.8.31). Security gates block on defined criteria (e.g. no new critical SAST/SCA findings). Tune to avoid alert fatigue: fail the build on high-confidence criticals, triage the rest into the backlog with SLAs (A.8.8).

16A.2 Threat Modelling, Practical Methods

Threat modelling at design is the highest-ROI secure-development activity, because design flaws are the most expensive to fix later. Use a lightweight, repeatable method: STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) against a data-flow diagram, or the OWASP "four questions" (What are we building? What can go wrong? What are we doing about it? Did we do a good job?). Threat-model significant designs and changes (new services, sensitive data flows, auth changes), not every trivial change. Capture mitigations as security requirements that flow into the backlog and tests.

16A.3 Tuning SAST/DAST/SCA (avoiding the noise trap)

The fastest way to kill a secure-development programme is to drown developers in false positives. Tune: baseline existing findings so new code is the focus; prioritise by exploitability and reachability, not raw count; suppress confirmed false positives with justification; integrate findings into the developer's workflow (PR comments, IDE) rather than a separate portal; and fail the gate only on high-confidence criticals. The goal is a signal developers trust and act on, not a dashboard they learn to ignore.

16A.4 Security Champions and AppSec Culture

A central security team cannot review every change in a fast-moving engineering org. Security champions, developers within each squad with extra security training and a link to the AppSec team, scale the culture: they advocate for secure design, triage findings locally, and bring security questions back to the experts. Pair with role-based AppSec training (link 27002 (h)), secure-coding standards per language (A.8.28), and recognition. Culture, not tooling, is what makes secure development stick.

16A.5 Securing the Pipeline and Environments

The pipeline itself is an attack surface (the SolarWinds lesson). Harden it: least-privilege, short-lived pipeline identities (A.5.16 non-human identity); signed build artefacts and provenance (SLSA, Sigstore); secured, access-controlled repositories and protected version control (A.8.4, A.8.32); and strict dev/test/prod separation (A.8.31) with no production data in non-production, use masked or synthetic data (A.8.11, A.8.33). A secure SDLC with an insecure pipeline is a contradiction.

16A.6 Frameworks: SSDF, SAMM and ASVS

Anchor the programme to a recognised framework so it is structured and measurable: NIST SSDF (SP 800-218) defines secure-development practices (Prepare the Organisation, Protect the Software, Produce Well-Secured Software, Respond to Vulnerabilities) and is increasingly referenced in customer and regulatory requirements; OWASP SAMM provides a maturity model to assess and improve the program; and OWASP ASVS gives a verification standard for application security testing. Mapping your SSDLC to one of these makes audits and customer security reviews far smoother.

16A.7 Secure-Development Maturity Model (L1–L5)

Certification does not require a set maturity level. Most organisations aim for L3; software product companies and regulated fintechs usually need L4 practices.

16A.8 Anatomy of an Application-Security Failure

A development team, under deadline pressure and with no SSDLC, ships a feature with an injection flaw (no secure-coding standard or SAST caught it) that also pulls in a known-vulnerable open-source library (no SCA). Security was "tested" only by a brief manual check at the end, which missed both. In production, an attacker exploits the injection flaw to reach a database that, because test used production data, also exposed real customer PII. Every link is an A.8.25 measure: secure coding + SAST, SCA on dependencies, security in design/testing, and environment separation with masked data. Building security in across the life cycle prevents the flaw rather than discovering it via breach.

Key Takeaways

• A.8.25 is the umbrella that orchestrates application-security controls (8.26–8.31) into one disciplined life cycle.
• Shift left and automate: SAST + SCA + secret scanning in CI, DAST/pen testing pre-release, with tuned security gates.
• Threat-model significant designs: design flaws are the highest-impact to fix later.
• Scale with security champions and training; culture makes secure development stick.
• Secure the pipeline and separate environments (no production data in non-prod), a secure SDLC needs both.
• Anchor to SSDF/SAMM; in India, A.8.25 supports DPDP safeguards, RBI application-security expectations and CERT-In SBOM guidance.

Multi-Framework Mapping

Implementation Roadmap

Phase 1, Framework (Weeks 1–3)

• Establish the SSDLC standard (align to SSDF/SAMM); define security requirements & checkpoints.
• Quick win: add SAST + SCA + secret scanning to CI.

Phase 2, Build In Security (Weeks 4–7)

• Introduce threat modelling and secure coding guidelines (8.28).
• Add DAST and pre-release penetration testing (8.29); set security gates.

Phase 3, Environments & Repos (Weeks 8–10)

• Enforce dev/test/prod separation (8.31) and masked test data (8.11/8.33).
• Secure repositories, version control, and CI/CD pipeline identities (8.4/8.32).

Phase 4, Culture & Assure (Weeks 11–12+)

• AppSec training + champions; integrate findings into vuln management (8.8).
• KPI dashboard; internal audit dry-run; extend rules to outsourced dev (8.30).

FAQ

Q1: Is A.8.25 mandatory for certification? Not automatically: it is selected through risk treatment (clause 6.1.3) and recorded in your Statement of Applicability. If you develop or significantly customise software or systems, you will normally include it, and auditors then expect a documented, applied SSDLC. Organisations that only buy software may exclude it with that reason and rely on A.5.20, A.5.21 and A.8.26.

Q2: How is A.8.25 different from A.8.28 and A.8.29? 8.25 is the umbrella SSDLC; 8.28 is secure coding within it; 8.29 is the security testing phase. 8.25 orchestrates all the application-security controls into one life cycle.

Q3: What's the highest-impact quick win? Add SAST + SCA + secret scanning to your CI pipeline, it catches code flaws, vulnerable dependencies and leaked secrets automatically on every build.

Q4: Do we need to threat-model everything? Threat-model significant designs and changes (new services, major features, sensitive data flows). Lightweight threat modelling at design is far cheaper than fixing design flaws later.

Q5: How does A.8.25 relate to the software supply chain (A.5.21)? SCA and SBOM connect them: securing your own development includes governing the third-party/open-source components you build with (5.21). A vulnerable dependency you ship is your responsibility.

Q6: Do customers expect an SBOM? Increasingly, yes, especially BFSI and government buyers. Generate one per release in your pipeline (CycloneDX or SPDX) and agree how you share it. The CERT-In SBOM guidelines describe the content.

Q7: We outsource development, does this still apply? Yes. Apply the SSDLC rules to your outsourced/sub-contracted developers contractually and obtain evidence (link A.8.30, A.5.20).

References and Further Reading

Primary standards

• ISO/IEC 27001:2022: Annex A control 8.25.
• ISO/IEC 27002:2022: Clause 8.25 (SSDLC aspects (a)–(j)); related §8.26, §8.27, §8.28, §8.29, §8.30, §8.31, §8.4, §8.32.
• ISO/IEC 27034 (series): Application security.

Supporting frameworks

• NIST SP 800-218: Secure Software Development Framework (SSDF).
• NIST SP 800-53 Rev 5: SA-3, SA-8, SA-11, SA-15.
• OWASP: SAMM, ASVS, Top 10, Proactive Controls.
• CIS Controls v8: Control 16 (Application Software Security).
• PCI DSS v4.0.1: 6.2.1–6.2.4, 6.3.2.
• NIST CSF 2.0: PR.PS-06.

Indian regulations

• Digital Personal Data Protection Act, 2023: Section 8(5); security/privacy by design.
• RBI: Master Direction on Digital Payment Security Controls (2021); Master Direction on IT Governance, Risk, Controls and Assurance Practices (2023).
• SEBI: CSCRF (2024). IRDAI: Information and Cyber Security Guidelines (2023).
• CERT-In: Technical Guidelines on SBOM (2024).

Singahi resources: the A.8.25 toolkit and related guides for A.8.26 Application security requirements, A.8.28 Secure coding, A.8.29 Security testing, and A.8.31 Separation of dev/test/prod.