Skip to content
AuditFront
A.8.26 ISO 27001

ISO 27001 A.8.26: Application security requirements

What This Control Requires

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

In Plain Language

Too many projects treat security as something to test for at the end rather than something to design for at the start. By the time a penetration test finds a fundamental architectural flaw, reworking it is painful and expensive. Security requirements need to be defined alongside functional requirements, right at the beginning of any development or procurement project. That means specifying authentication mechanisms, data protection needs, input validation, session management, error handling, logging, and regulatory compliance requirements - all before anyone writes a line of code or signs a contract. For bought applications (COTS or SaaS), security requirements should be part of your evaluation criteria. If a product does not meet your standards, you either find compensating controls, negotiate with the vendor, or choose a different product.

How to Implement

Set up a process that triggers security requirements gathering at the start of every application project, whether you are building or buying. Create a security requirements template that covers common areas and can be tailored per project. The core categories to address: authentication (MFA support, SSO integration, password policy enforcement), authorisation (RBAC, fine-grained permissions, API authorisation), data protection (encryption at rest and in transit, data masking, secure key management), input validation (server-side validation, parameterised queries, content security policies), session management (secure tokens, timeout, anti-CSRF), error handling (no information leakage in error messages), logging (security events, audit trails, log integrity), API security (authentication, rate limiting, input validation), and compliance (regulatory requirements, data residency). For internal development, integrate security requirements into your standard requirements process. Use threat modelling to surface additional requirements specific to the application context. Make sure security requirements appear in acceptance criteria and get validated during testing. For acquired applications, put security requirements in the RFP and evaluation criteria. Assess candidates through vendor security questionnaires, product security documentation, security testing of trial instances, and review of certifications and audit reports. Before any application goes live, validate that security requirements are actually met. Run SAST, DAST, and penetration testing to verify implementation. Document results and any accepted residual risks. Include security sign-off in the go-live approval. Build a reusable library of security requirements organised by application type and risk level. Update it as standards, threats, and regulations evolve. This saves time on each new project while keeping things consistent.

Evidence Your Auditor Will Request

  • Security requirements documentation for recent application projects
  • Security requirements template or checklist used across projects
  • Security evaluation records for recently acquired applications
  • Security testing results validating requirement implementation
  • Application go-live approval records including security sign-off

Common Mistakes

  • Security requirements are not defined during application development or acquisition
  • Security requirements are generic and not tailored to the specific application context
  • Acquired applications are not evaluated against security requirements before deployment
  • Security requirements are defined but not tested or validated
  • Security requirements do not address current threats and regulatory obligations

Related Controls Across Frameworks

Framework Control ID Relationship
SOC 2 CC8.1 Related
GDPR Art.25 Related
NIS2 Art.21(2)(e) Partial overlap

Frequently Asked Questions

What security requirements should we specify for web applications?
Start with the OWASP Top 10 as your baseline: injection prevention, proper authentication and session management, sensitive data protection, XXE prevention, access control, misconfiguration prevention, XSS prevention, safe deserialisation, dependency management, and logging/monitoring. Then layer on application-specific requirements based on data sensitivity and your threat model. The OWASP ASVS (Application Security Verification Standard) is a great structured checklist for this.
How do we handle security requirements for SaaS applications we cannot modify?
Evaluate against your requirements during selection - that is your biggest leverage point. For gaps the product does not natively cover, you have a few options: implement compensating controls on your side (a CASB for additional access controls, for example), negotiate with the vendor for feature additions, accept the residual risk with documented management approval, or choose a different vendor. Whatever you decide, document the gaps and any compensating controls clearly.

Track ISO 27001 compliance in one place

AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.

Start Free Assessment