Application security requirements
Purpose
Identify, specify and approve information security requirements whenever applications are developed or acquired.
How to meet this control
In short: Identify, specify and approve security requirements for applications.
- Step 01Capture security requirements alongside functional ones in tickets and specifications, derived from risk assessment with security input
- Step 02Define the identity trust level and the classification of data each application handles
- Step 03Specify defences against common attacks such as injection and broken access control, plus input validation and output encoding
- Step 04Address privacy and legal requirements for the relevant jurisdictions and protect data in process, transit and at rest
- Step 05For transactional and payment flows, define authorisation, proof of dispatch and receipt and secure storage of transaction data
- Step 06Approve the security requirements before build and verify them in testing
Tip: Capture security requirements in tickets/specs, not just functional ones.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Determine requirements through risk assessment with input from security specialists
- ›Define the trust level needed for identity and the classification of information handled
- ›Specify segregation of access, resilience against attacks like injection, and privacy needs
- ›Address legal requirements for the relevant jurisdictions and protect data in process, transit and rest
- ›Set input controls such as validation, automated controls like approval limits, and output controls
- ›Control free-text fields, error message handling and transaction logging needs
- ›For transactional services, define trust levels, signing authorisation and proof of dispatch and receipt
- ›For payment, protect order confidentiality, verify payment data and store transaction details securely
Audit evidence to keep
- - Security requirements recorded in tickets or specification documents
- - Risk assessment informing the application requirements
- - Acceptance criteria covering injection, access control and validation
- - Evidence of payment or transaction security requirements where applicable
- - Sign-off that security requirements were approved before build
Common mistakes
- - Writing a policy but not operating the process
- - Keeping evidence in personal folders where auditors cannot trace it
- - Letting exceptions stay open with no owner or expiry date
Owner, cadence, and proof
Assign one accountable owner for A.8.26. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.