Applications are where data is processed, decisions are made, and money often changes hands.
If application security is weak, every upstream control is undermined.
Annex A 8.26 exists to ensure organisations define and apply appropriate information security requirements for applications, whether they are developed in-house, purchased, customised, or provided as a service.
This control is about making security a defined requirement of applications — not an afterthought.

Annex A 8.26 of ISO 27001:2022 focuses on application security requirements.
At a practical level, this means:
The control does not prescribe specific technologies. It expects clear, risk-based requirements that are deliberately applied and maintained.
Applications are frequently the primary cause of:
This is because applications:
If security requirements are not clearly defined:
Annex A 8.26 ensures organisations know what security an application is expected to provide — and why.
This control replaces ISO 27001:2013 Annex A 14.1.2 and 14.1.3, expanding the scope from public network applications to all applications.
A pragmatic approach to Annex A 8.26 typically includes the following elements.
Organisations should determine security requirements by considering:
Requirements should be risk-driven, not copied blindly across all systems.
Security requirements should reflect:
Applications that process sensitive data require stronger controls by design.
Applications should clearly define:
This aligns closely with:
Weak identity assurance undermines all other controls.
Annex A 8.26 supports defining:
Access should follow:
Function-level access control is as important as application-level access.
Application security requirements should address:
Cryptographic controls may be required where risk justifies it.
Applications should define requirements for:
Free-text input fields should be controlled to prevent:
Unchecked input is one of the most common application weaknesses.
Where appropriate, applications should:
This is particularly relevant for:
Error messages should be designed to:
Helpful to users does not mean helpful to attackers.
Application security requirements should reflect:
Compliance obligations should be built into application behaviour, not bolted on later.
Where applications support transactions with external parties, requirements should consider:
Transactional failures often become legal failures.
For ordering and payment applications, organisations should consider:
Payment systems magnify the impact of design weaknesses.
Security requirements should apply during:
This aligns directly with the secure development life cycle (Annex A 8.25).
Annex A 8.26 does not require:
It does require organisations to:
Undefined security requirements are indistinguishable from no requirements.
Most application failures are requirement failures.
Annex A 8.26 is about making security a deliberate property of applications.
When application security requirements are defined and applied effectively:
Applications do not fail randomly.
They fail according to the requirements they were given.
Annex A 8.26 ensures organisations give them the right ones.
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