Integrate ISO 27001 Controls into the Secure SDLC

Integrating ISO/IEC 27001 into the system and software development life cycle means making information-security decisions at the points where they can still change an outcome. A policy that says development must be secure is not enough. Teams need defined responsibilities, risk-based gates and evidence that the controls operated for real changes.

The aim is not to create a second delivery process owned by security. It is to place appropriate security activities inside the organisation’s existing product, project and engineering flow. The result should be traceable from business need and risk through design, build, test, release, operation and retirement.

Understand the current control chain

ISO/IEC 27001:2022 Annex A control 8.25 addresses the secure development life cycle. It connects with controls for application security requirements, secure architecture, secure coding, security testing, outsourced development, separation of environments, change management and protection of test information. Project security under A.5.8 and supplier controls may also apply.

These controls are reference controls selected through risk treatment; they are not a prescribed development method. An organisation may use Scrum, Kanban, staged delivery, DevOps or a hybrid approach. What matters is that the chosen controls are appropriate, owned, implemented and supported by evidence.

The Annex A control lookup helps teams view these controls as a connected set rather than isolated clauses.

Start with risk-based delivery tiers

Applying the same assurance to every change wastes effort and can encourage teams to bypass the process. Define delivery tiers using observable factors such as:

• information sensitivity and transaction value;
• external exposure and number of users;
• privileged, safety-related or business-critical functions;
• legal, regulatory and contractual duties;
• use of new technology or complex integrations;
• supplier involvement;
• expected rate of change; and
• impact if confidentiality, integrity or availability fails.

A low-risk change to an internal information page may need peer review and automated tests. A new internet-facing payment service may need threat modelling, independent security testing, architecture approval and evidence of remediation before release.

Record who assigns the tier, the criteria used, when it must be reassessed and who can approve an exception. The threat and vulnerability catalogue guide explains how reference material can support this judgement without replacing scenario-based risk analysis.

Put controls at lifecycle decision points

Security activities are most useful when they produce or change a delivery decision.

Lifecycle point	Security decision	Useful evidence
Idea and planning	Is the change in scope, and what risk tier applies?	Intake record, data classification, initial risk decision
Requirements	What security outcomes and obligations must be met?	Traceable requirements, acceptance criteria, privacy or legal input
Architecture	Are trust boundaries, dependencies and failure modes understood?	Data-flow diagram, threat model, architecture decision record
Build	Are approved coding and dependency practices operating?	Review records, pipeline results, dependency decisions
Verification	Has the product met its risk-based security criteria?	Test plan, results, defect treatment, acceptance decision
Release	Is residual risk understood and authorised?	Gate approval, deployment record, exception or risk acceptance
Operation	Do monitoring, vulnerability and incident processes cover the service?	Alerts, maintenance records, vulnerability tickets, incident links
Retirement	Are data, access, integrations and assets removed safely?	Decommission plan, revocation records, disposal and closure evidence

This table is AuditPrepared guidance, not a requirement to use named gates. A continuous-delivery team can automate many decisions. The important point is that evidence remains available and authority matches the risk.

Define security requirements before design hardens

Security requirements should describe testable outcomes. “Use strong security” cannot be verified. Better requirements identify the protected asset, expected behaviour, conditions and verification method.

Sources may include risk treatment, customer commitments, regulation, data classification, architecture principles, prior incidents and known attack patterns. Each material requirement should have an owner and a link to a design or test outcome. Requirements also need change control: an approved requirement that disappears during delivery creates hidden residual risk.

The OWASP application-security evidence guide shows how open security resources can support detailed requirements and tests. They remain implementation aids; the organisation still owns scope, risk and acceptance.

Make architecture review proportional and repeatable

Architecture evidence should show why the design can meet the requirements. For higher-risk changes, examine data flows, trust boundaries, authentication, authorisation, encryption, secrets, logging, resilience and administrative paths. Record key decisions and rejected alternatives when they affect risk.

Reviewers should have sufficient independence for the risk. The original designer can perform a self-review for routine work, while a critical service may need a separate security architect. Independence does not necessarily mean an external party; it means the reviewer is able to challenge the design objectively.

Avoid approving a static diagram and assuming the control is complete. Compare the implemented environment with the design after deployment. Infrastructure-as-code, cloud configurations and service inventories can provide stronger operating evidence than a presentation alone.

Embed controls in engineering work

Turn expectations into normal delivery mechanisms:

• approved repositories and protected branches;
• peer review for material changes;
• automated tests appropriate to the technology;
• controlled dependency introduction and update;
• secrets kept outside source code;
• separation of development, test and production access;
• restricted and representative test data;
• traceable build and deployment records; and
• defined handling of failed scans or tests.

Automation improves consistency but does not prove that the configured rules are suitable. Preserve configuration, rule ownership, change history and exception decisions. A pipeline showing “passed” is weak evidence if nobody can explain what was tested or whether the relevant components were in scope.

Control outsourced development through outcomes

Contract language alone does not demonstrate control of outsourced development. Define security requirements, deliverables, evidence, access boundaries, defect handling, intellectual-property needs and exit arrangements before work begins. Decide how the organisation will verify results instead of relying only on supplier statements.

Useful evidence may include supplier design reviews, test summaries, remediation records, code escrow or transfer arrangements, repository access history and acceptance approvals. The supplier security lifecycle guide provides a broader approach for onboarding, monitoring and exit.

Join release, operation and retirement

The secure development life cycle does not end when code reaches production. Release criteria should confirm monitoring, support ownership, recovery arrangements, vulnerability handling and runbooks. New services should enter asset, dependency and logging inventories.

Operational events must feed back into development. Incidents, repeated defects, failed recoveries and vulnerability trends can reveal a weak requirement or design principle. Record the resulting improvement so the organisation can demonstrate learning rather than repeated correction.

Retirement deserves the same discipline. Revoke identities and keys, remove network routes, archive required records, dispose of data according to obligations, update inventories and confirm that dependent services no longer call the retired component.

Test both design and operation

An audit should sample completed changes across risk tiers, teams and delivery models. For each sample, trace the work from intake to release and operation.

Useful questions include:

• How was the risk tier assigned, and did later changes trigger reassessment?
• Which security requirements came from risk and obligations?
• Can the team show that architecture decisions reached the deployed design?
• What happens when an automated or manual security test fails?
• Who can accept residual risk, and was that authority used correctly?
• Did supplier evidence meet the agreed acceptance criteria?
• Are production monitoring and vulnerability processes connected to the service?

Testing one successful flagship project may hide inconsistent operation. Include a routine change, an urgent change, a supplier-delivered change and a higher-risk release where those populations exist.

Judge evidence quality

A pass is supported when lifecycle controls are defined by risk, owners understand them and sampled changes show consistent requirements, decisions, tests, exceptions and release evidence.

A partial result may exist when the process is sensible but evidence is incomplete, one team operates outside it, risk tiers are inconsistently assigned or exceptions lack timely approval.

A fail is likely when security is considered only after build, material changes bypass review, testing failures do not affect release, or the organisation cannot connect its policy to operating records.

Use the ISO 27001 readiness checker to place secure-development findings in the wider ISMS rather than assessing engineering in isolation.

Keep the lifecycle useful

Measure whether the process changes outcomes. Review recurring defect classes, late security discoveries, exception age, unplanned security work and differences between risk tiers. These are management signals, not universal ISO metrics. Choose measures that help owners improve decisions.

The official ISO/IEC 27002 overview describes the standard as guidance on information-security controls. The NIST Secure Software Development Framework offers a complementary set of secure-development practices that organisations can adapt to their technology and risk.

Effective integration is visible in ordinary delivery records. When security requirements, design decisions, verification and acceptance are part of normal work, the organisation can demonstrate more than an approved process: it can show that security influenced what was built and released.