Most software vulnerabilities are not caused by attackers.
They are designed in, long before code ever reaches production.
Annex A 8.25 exists to ensure organisations embed information security throughout the secure development life cycle (SDLC), from initial design through development, testing, deployment, and change.
This control is about building security in, not bolting it on at the end.

Annex A 8.25 of ISO 27001:2022 focuses on the secure development of software, systems, and applications.
At a practical level, this means:
The control does not mandate a specific development methodology. It expects security to be a consistent and explicit part of how systems are built and changed.
Historically, many organisations treated security as:
The result was predictable:
Annex A 8.25 ensures organisations address security from the outset, when change is cheapest and risk is easiest to control.
This control replaces ISO 27001:2013 Annex A 14.2.1 and strengthens expectations around testing, licensing, and secure engineering practices.
A pragmatic approach to Annex A 8.25 typically includes the following elements.
Organisations should define rules covering:
This applies to:
Security should be part of “how we develop”, not an optional overlay.
Security requirements should be considered during:
This may include:
Fixing a design flaw later is significantly more expensive.
Annex A 8.25 explicitly supports environment separation.
Organisations should ensure:
Environment separation reduces both security and operational risk.
Where code is written, organisations should:
Secure coding expectations should be:
Insecure code is rarely accidental — it is usually unmanaged.
Modern development relies heavily on third-party components.
Annex A 8.25 expects organisations to:
Supply chain risk does not stop at infrastructure.
Security testing should not be limited to the end of development.
Organisations should consider:
Annex A 8.25 explicitly supports:
Late testing finds problems when options are limited.
Source code and configurations should be:
This aligns closely with:
Uncontrolled code repositories are high-value targets.
Changes introduced through development should:
This supports:
Rapid delivery does not remove the need for control.
Annex A 8.25 explicitly recognises people as a control.
Organisations should ensure developers:
Tools do not compensate for lack of knowledge.
Where development is outsourced, organisations should ensure:
Outsourced development remains organisational risk.
Annex A 8.25 does not require:
It does require organisations to:
Most serious application vulnerabilities are known patterns repeated.
Secure development failures are usually process failures.
Annex A 8.25 is about reducing risk before systems ever go live.
When a secure development life cycle is implemented effectively:
You cannot patch your way out of poor design.
Annex A 8.25 ensures organisations design security in from the start.
We can help you understand your actual security needs and even if we cant help we can point you in the right direction
Talk to a security expert today