8.25: Secure development life cycle | ISO 27001

Software ships with exploitable flaws every day, not because development teams lack skill, but because security was treated as a final checkpoint rather than a continuous practice. Vulnerabilities discovered after deployment are dramatically more expensive to remediate. According to HackerOne, fixing a vulnerability in production costs 30x more than catching it during the design phase. ISO 27001 Annex A Control 8.25 exists to close that gap, requiring organizations to embed security into every stage of the development lifecycle so flaws are caught before they reach production.

What 8.25 requires

ISO 27001 Annex A Control 8.25 requires organizations to establish and enforce rules for secure software and system development, ensuring that security is integrated into every stage of the development lifecycle from design through deployment. The core question it answers is one every development team faces. What does your organization actually have to do to build software securely?

The control mandates several concrete obligations:

• Written Secure Development Policy: Organizations must document a formal policy that defines security expectations across all in-scope development activities, including in-house applications, middleware, services, and system components.
• Security gates at each phase: Development projects must include defined security checkpoints at requirements gathering, design, implementation, testing, and deployment. Each gate should have clear pass/fail criteria.
• Environment separation: Development, testing, staging, and production environments must be logically and, where appropriate, physically separated with distinct access controls.
• Secure coding** standards:** Teams must adopt and follow recognized coding standards, such as the Open Worldwide Application Security Project (OWASP) guidelines or language-specific security rules, to reduce common vulnerability patterns.
• Trained developers: Personnel involved in development must receive security awareness training relevant to their role, covering topics like injection prevention, authentication best practices, and secure dependency management.

The logic behind these requirements reflects a well-documented principle in software engineering: catching flaws early is orders of magnitude cheaper than remediating them after deployment. A missing input validation check caught during design review takes minutes to address. The same flaw discovered through a production incident triggers incident response, emergency patching, regression testing, and potential customer notification.

8.25 also requires organizations to consider security requirements for the development environment itself, including version control protections, access controls on build pipelines, and integrity checks for development tools. The control applies regardless of development methodology, whether teams use waterfall, agile, DevSecOps, or any hybrid approach.

Why 8.25 matters

An organization pushes a web application update through an accelerated release cycle. No security review occurs before deployment. Within weeks, an external researcher discovers a Server-Side Request Forgery (SSRF) vulnerability in the new feature. Before the team can patch it, an attacker leverages the flaw to access internal services, exfiltrate customer records, and pivot into connected systems. The resulting data exposure triggers regulatory notification requirements, customer churn, and months of remediation work.

This pattern is not hypothetical. Fortinet’s FortiGuard Labs reported over 30,000 new vulnerabilities disclosed in 2024, representing a 17% year-over-year increase. The sheer volume of new weaknesses means organizations without structured secure development practices are statistically likely to ship exploitable code.

The risk classes that 8.25 addresses go beyond individual application bugs:

• Application-layer compromise: Attackers exploit coding flaws to gain unauthorized access, escalate privileges, or execute arbitrary commands.
• Data exposure: Poor input handling, broken authentication, or insecure data storage can leak sensitive information to unauthorized parties.
• Supply chain risk: Vulnerable code shipped to customers or integrated into partner systems propagates risk across organizational boundaries.

Without 8.25’s structured approach, security becomes reactive. Teams spend their time firefighting production vulnerabilities instead of preventing them, and the cost compounds with every release. Every unreviewed deployment widens the window of exposure, and each new vulnerability adds to a backlog that security teams struggle to triage. The financial impact extends beyond direct remediation to include regulatory penalties, legal costs, lost revenue during outages, and the long-term erosion of customer trust that follows a public breach disclosure.

What attackers exploit

Attackers consistently target the same failure modes in organizations that lack a mature Secure Development Life Cycle (SDLC):

• Missing security requirements in the design phase, leaving entire threat categories unaddressed
• No separation between development, testing, and production environments, allowing lateral movement
• Hard-coded secrets in source code repositories, accessible through commit history
• No code review or peer review process, permitting vulnerable code to reach production unchallenged
• Unpatched third-party dependencies with known Common Vulnerabilities and Exposures (CVEs)
• Lack of security testing, with no Static Application Security Testing (SAST) or Dynamic Application Security Testing (DAST) in the pipeline
• Developers with direct production access bypassing change controls

How to implement 8.25

For your organization (first-party)

Implementing 8.25 effectively means embedding security into existing development workflows rather than creating parallel processes that teams will circumvent. The following steps align with the control’s requirements while remaining practical for organizations at varying maturity levels.

1. Draft a Secure Development Policy covering all in-scope development activities. The policy should define which projects fall under scope (custom applications, integrations, internal tools, Infrastructure as Code), assign security responsibilities for each development role, and reference the coding standards and testing requirements teams must follow. Avoid writing a policy that sits on a shelf. Tie it directly to project kickoff checklists and definition-of-done criteria so it becomes part of daily workflow.

2. Enforce environment separation with distinct access controls. Maintain separate development, testing, staging, and production environments. Each environment should have its own credentials, network segmentation, and access policies. Developers should never have standing access to production data or systems. Use role-based access controls aligned with the principle of least privilege, following guidance from NIST Special Publication (SP) 800-53 AC-6.

3. Embed security requirements into design specs and user stories. Security shouldn’t be a separate workstream. When teams write user stories or design documents, they should include abuse cases, threat models using frameworks like STRIDE or PASTA, and acceptance criteria that address authentication, authorization, input validation, and data protection.

4. Adopt secure coding standards. Mandate adherence to OWASP Secure Coding Practices, CERT Secure Coding Standards for the relevant language, or equivalent guidelines. These standards should be integrated into linting tools and Integrated Development Environment (IDE) plugins so developers receive real-time feedback.

5. Integrate security testing into Continuous Integration/Continuous Deployment (CI/CD) pipelines. Run SAST on every commit, dependency scanning against the National Vulnerability Database (NVD) and vendor advisories, and DAST against staging environments before production deployments. These checks should be automated gates that block deployment when critical findings are detected.

6. Require code review for all production-bound changes. Every merge request should receive at least one peer review, with a security-focused reviewer assigned for changes touching authentication, authorization, cryptography, or data handling logic. Document review outcomes in the version control system.

7. Secure repositories and version control with role-based access. Protect branches with merge rules, require signed commits where practical, and audit repository access regularly. Secrets scanning tools should run on every push to prevent credentials from entering the codebase.

8. Train developers on secure coding and security awareness. Training should go beyond annual compliance checkboxes. Provide hands-on workshops, capture-the-flag exercises, and ongoing access to resources like OWASP’s Security Knowledge Framework. Track completion and competency, not just attendance.

9. Log and audit deployments. Maintain immutable records of who deployed what code, when, and through which approval process. Deployment logs should tie back to specific change requests and code review records, creating a complete audit trail.

The evidence you’ll need to produce includes the Secure Development Policy itself, coding standards documentation, security gate records from each project phase, SAST/DAST scan results, training completion logs, and deployment audit trails.

Common mistakes undermine even well-intentioned implementations. Organizations write a comprehensive policy but never embed its requirements into project templates or CI/CD configurations. Teams run a penetration test only at the end of the project, missing the cost savings of earlier detection. Developers receive standing production access “for convenience,” violating separation of duties. Third-party library vulnerabilities go untracked because dependency scanning isn’t automated, and organizations often lack a complete Software Bill of Materials (SBOM) for their applications. Low-code or no-code development platforms are treated as exempt from security review despite processing sensitive data.

The scale of unaddressed risk is significant. ReversingLabs found that 48.5% of enterprise applications contain high-risk unresolved vulnerabilities that have been open for over a year, underscoring how many organizations fail to operationalize security testing within their development processes.

For your vendors (third-party assessment)

When assessing vendors against 8.25, the goal is to determine whether their development practices protect the data and systems your organization entrusts to them. A thorough vendor security review starts with targeted questions during the assessment process:

• “Describe your Secure Development Life Cycle, including which framework or standard it follows.”
• “How do you separate development, testing, and production environments?”
• “What security testing do you perform, and at which stages of the development lifecycle?”
• “How do you manage third-party dependencies, including vulnerability monitoring and patching timelines?”

Request supporting evidence to validate their responses:

• Secure Development Policy documenting their SDLC requirements
• Recent penetration test report from a qualified third party
• SAST/DAST scan results showing testing frequency and remediation patterns
• Environment architecture diagram demonstrating separation between development, testing, and production

Several red flags should trigger deeper investigation. A vendor that can’t describe their SDLC in concrete terms, or provides only vague assurances, likely lacks a mature program. Absence of security testing evidence, developers with direct production access, and no dependency management process all indicate significant risk.

For verification, request a SOC 2 Type II report or ISO 27001 certificate covering their development operations. Organizations can use an ISO 27001 vendor questionnaire to standardize this assessment. Review any public vulnerability disclosure process the vendor maintains, and check databases like the MITRE CVE list for known vulnerabilities in their products. Pay attention to the vendor’s patch cadence as well; a vendor that takes months to address known CVEs in their products signals a development process that lacks the urgency 8.25 demands.

Vendors that provide Software as a Service (SaaS) products warrant particular scrutiny because their development practices directly affect the confidentiality, integrity, and availability of your data. Understanding the broader ISO 27001 third-party risk requirements helps contextualize what to look for. Request evidence of automated security testing in their CI/CD pipelines and confirm that their release processes include security sign-off gates. UpGuard Vendor Risk helps organizations systematically assess and monitor vendor security practices, including development lifecycle controls, through automated questionnaires and continuous monitoring.

Audit evidence for 8.25

Auditors assessing 8.25 compliance expect documented evidence across several categories. The following artifacts demonstrate that secure development controls are implemented and operating effectively. An ISO 27001 implementation checklist can help track readiness across all required evidence categories.

Cross-framework mapping

Control 8.25 aligns with security development requirements across multiple frameworks, making it a useful anchor point for organizations managing compliance with several standards simultaneously. Organizations pursuing multiple certifications can leverage their 8.25 implementation to satisfy overlapping requirements, reducing duplicated effort across audit cycles.

Related ISO 27001 controls

8.25 connects to several other Annex A controls that address overlapping aspects of secure development and operations.

Frequently asked questions

What is ISO 27001 8.25?

ISO 27001 Annex A Control 8.25 requires organizations to establish rules for secure software and system development that integrate security across the entire development lifecycle. It covers written policies, secure coding standards, environment separation, security testing, code review, and developer training to ensure vulnerabilities are identified and addressed before code reaches production.

What happens if 8.25 is not implemented?

Organizations without 8.25 controls routinely ship vulnerabilities to production, where remediation costs multiply and attacker exposure windows widen. The consequences include audit non-conformities that can jeopardize ISO 27001 certification, increased risk of data breaches through exploitable application flaws, and reputational damage when vulnerabilities are publicly disclosed.

How do you audit 8.25?

Auditors verify 8.25 by reviewing the documented Secure Development Policy, examining evidence of security gates at each development phase, confirming environment separation between development and production, and inspecting security testing records from CI/CD pipelines. They also check developer training logs and deployment audit trails to confirm that controls are consistently applied rather than existing only on paper.

How UpGuard helps

Secure development practices reduce the vulnerabilities that reach production, and continuous external monitoring catches what slips through. UpGuard provides the attack surface visibility that complements internal SDLC controls.

• Breach Risk: Continuously monitors your external attack surface for vulnerabilities, exposed services, and misconfigurations that insecure development practices can introduce, giving security teams immediate visibility into production-facing risks.
• Vendor Risk: Automates third-party security assessments, including evaluation of vendor secure development practices, through standardized questionnaires and continuous monitoring of vendor security posture.