ISO 27001 A.8.26 - Application Security Requirements

Requirement

“Information security requirements shall be identified, specified and approved when developing or acquiring applications.”

Plain-language meaning

Application security requirements should be defined before the application is built, bought, integrated, or changed. The organization should decide what security the application needs, document those requirements, and approve them.

This applies to internal applications, customer-facing services, websites, APIs, SaaS, industrial systems, payment/transaction systems, and acquired commercial applications.

Why this matters

Applications often process sensitive transactions, credentials, personal information, billing details, customer data, and business records. If requirements are not defined early, security is guessed later or retrofitted badly.

Security requirements can include authentication, authorization, cryptography, logging, transaction validation, secure protocols, fraud prevention, segregation of duties, privacy, legal compliance, and network protection.

Implementation guidance

1. Identify application security requirements

Use risk assessment, classification, privacy obligations, legal/contractual obligations, architecture, transaction risk, user roles, and threat modelling to define requirements.

2. Specify requirements clearly

Avoid vague requirements like “application must be secure.” Define testable requirements for access control, cryptography, logging, input validation, transaction verification, secure protocols, data storage, monitoring, and administration.

3. Approve requirements

Security requirements should be approved by the appropriate business owner, system owner, security role, and other relevant stakeholders before development or acquisition decisions proceed.

4. Address transaction and public-network risks

Applications that process transactions over public networks may need stronger controls for authenticity, integrity, confidentiality, non-repudiation, certificate trust, user credential verification, payment validation, monitoring, and legal compliance.

5. Carry requirements into testing and acceptance

Security requirements should be verified before go-live or acceptance. Procurement, development, testing, and release records should show whether requirements were met or risk-accepted.

Audit guidance

Auditors should verify:

• application security requirements are identified for new, changed, and acquired applications;
• requirements are risk-based and specific;
• requirements are approved by appropriate owners;
• authorization, segregation of duties, cryptography, network security, logging, and transaction verification are considered where relevant;
• public network and transaction services have appropriate protections;
• certificate authorities and digital signature processes are managed where used;
• secure communication protocols and secure storage are specified;
• legal/regulatory requirements are considered;
• requirements are tested before release or acceptance;
• exceptions are approved and risk-treated.

Evidence examples

Strong evidence

• Requirements are specific and testable.
• Requirements trace to risk, data classification, and legal needs.
• Application owner and security approver sign off.
• Testing proves requirements were met.
• Transaction services include verification, secure protocols, and monitoring.
• Exceptions are documented and risk-accepted.

Weak evidence

• Security requirements are vague or absent.
• Procurement assumes vendor security without requirement mapping.
• Requirements are added after design is complete.
• Transaction controls are undocumented.
• Cryptographic controls are chosen without key-management policy.
• No evidence shows security requirements were tested.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.8.24 Use of Cryptography
• A.8.25 Secure Development Life Cycle
• A.8.27 Secure System Architecture and Engineering Principles
• A.8.20 Networks Security
• A.8.15 Logging
• A.5.8 Information Security in Project Management
• A.5.15 Access Control
• A.5.31 Legal, Statutory, Regulatory and Contractual Requirements
• Risk Assessment
• Statement of Applicability
• Application Security Requirements Register
• Application Transaction Security Checklist
• Application Security Requirements Approval Record
• A.8.26 Audit Evidence Pack
• A.8.26 Audit Checklist

KB-ready summary

• Identify security requirements early.
• Specify requirements clearly.
• Approve requirements before selection or build.
• Include transaction, crypto, network, legal, and logging needs.
• Test requirements before go-live.

Templates and checklists

• Application Security Requirements Register
• Application Transaction Security Checklist
• Application Security Requirements Approval Record
• A.8.26 Audit Checklist