A.8.26
Application security requirements
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Identify, specify, and approve information security requirements for applications.
Points of focus
- Security requirements are captured as part of feature specs or ticket templates, not a separate afterthought process
- Requirements cover authentication, authorization, input validation, and data handling per classification
- Requirements for third-party integrations and APIs address authentication and rate/abuse limits
- A named approver (security engineer, tech lead) signs off on requirements for higher-risk features
- Requirements are traceable to the resulting acceptance criteria and tests
Implementation notes
Bake a lightweight security-requirements section into the templates engineers already use — the ticket, the RFC, or the design doc — rather than standing up a separate security-requirements process that competes for attention with the normal workflow. For any feature touching customer data, ask three questions up front: who should be able to access this data and under what role or scope, what should be logged when it's accessed or changed, and what happens with data the user doesn't own (cross-tenant isolation is the single most common source of severe SaaS vulnerabilities). For new or modified API endpoints, specify the authentication scheme, expected rate limits, and input validation rules as part of the design rather than leaving them to be inferred from the framework's defaults. Apply the same rigor to internal tools and admin panels as to customer-facing surfaces — these often hold broader data access with weaker scrutiny and are a frequent finding in real incidents. For higher-risk features (new authentication flows, payment handling, bulk export capabilities), require a named reviewer's sign-off on the requirements before implementation begins, and keep that approval visible in the ticket history. Finally, close the loop by making sure acceptance criteria and test cases actually reference the stated security requirements, so 'done' includes 'the security requirement was verified,' not just 'the feature works.'
Audit tip: Pull up the ticket or spec for a recent feature that reads or writes customer data and ask the engineer to point to where the authorization and data-handling requirements were specified before the code was written — not the pull request description written afterward to explain what was built.
Evidence auditors typically request:
- Feature spec or ticket template with a required 'security requirements' or 'security considerations' section
- A sampled ticket for a customer-data-facing feature showing authorization rules and data-handling notes
- API design doc specifying authentication scheme, rate limiting, and input validation for a new endpoint
- Sign-off or approval comment from a security reviewer on a higher-risk feature's requirements
- Acceptance criteria or test cases that map back to the stated security requirements
Common gaps
- The ticket template has a security section but engineers routinely leave it blank or write 'N/A' without anyone checking
- Security requirements exist for the core product but are skipped for internal tools and admin panels that also touch customer data
- API endpoints ship without documented rate limiting or input-validation requirements, discovered only after an abuse incident
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.8.26 | This control |
| SOC 2 | CC8.1 | Related Trust Services Criteria themes — map in your crosswalk; not identical requirements. |
| GDPR | Article 25 | Related GDPR articles for personal-data security or processor themes — not a compliance claim. |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.8.26)