Application Security Requirements - ISO 27001 Annex A Control

ISO 27001 Annex A 8.26

Security requirements written at the start cost a fraction of those discovered at release.

ISO 27001 Annex A 8.26 - Application Security Requirements

Application security starts with requirements. Without explicit security requirements, security gets handled implicitly - which usually means inconsistently. The control asks for security requirements to be identified at the start of development or acquisition, specified clearly enough to be implementable, and approved as part of the wider requirements process.

Typical security requirements cover authentication and authorisation, data protection (encryption at rest and in transit), audit logging, error handling that does not leak sensitive information, input validation, and operational concerns such as backup and patching. The exact set depends on the application's role - a public-facing payment application has very different requirements from an internal reporting tool.

For acquired applications, the requirements drive the procurement assessment. Suppliers should be able to demonstrate how their product meets the requirements - through certifications, documentation, demonstrations, or contractual commitment. Where the product falls short, the gap needs to be addressed before the procurement proceeds rather than left for discovery later.

The audit checks that security requirements are actually present at the start of the development or acquisition. Where they appear only at the end as a security review finding list, the control is not operating in the order intended. The fix is to embed security requirements in the standard requirements template so they are considered as a matter of course.

Practical Compliance Guidance

Application security requirements are described in the IMS1 manual at section 8.5 alongside the Information Security Policy. Requirements documents and security review records provide the operational evidence.

alphaZ document How to use it
ISO 27001 Toolkit The full alphaZ ISO 27001 toolkit covering manual, policies, procedures, registers and audit checklists.
PP-8-100 Information Security Policy Procedure Contains the Information Security Policy including the security requirements baseline for applications. Use as the source for the requirements that apply to development and acquisition.

Note - all the above files can be downloaded with an alphaZ subscription.

Frequently Asked Questions

From a combination of the wider information security policy, applicable regulation (data protection, payment card standards, sector rules), the threat model for the specific application, and any contractual or customer requirements. The starting point is usually a baseline applicable to all applications, with extensions for specific risks.
The requirements drive the supplier security assessment. The supplier should demonstrate compliance through certifications (ISO 27001, SOC 2), security documentation, and contractual commitment. Gaps should be addressed before procurement and tracked as supplier risk under A.5.19-A.5.22.
Agile does not remove the need for security requirements - it changes how they are handled. Requirements may emerge through epics and stories rather than upfront documents, but they still need to be explicit, prioritised and addressed before release. Definition-of-done criteria for security help embed this into the development flow.

Further Resources

payment logos