Skip to main content

Proof of competence

Menu

ISO 27001 Annex A 8.26: Application Security Requirements – Practical Implementation Guide

ISO/IEC 27001:2022 Annex A · Control 8.26

Application Security Requirements: A Practical Implementation Guide

Define testable security requirements before architecture and code make changes expensive.

This control concerns identifying, specifying and approving information security requirements when developing or acquiring applications.

Practical interpretation: Requirements should come from risks, data, users, abuse cases, law and operations, and be precise enough to design and test.

What should the control achieve?

  • Requirements reflect application context and risk.
  • Security requirements are testable and traceable.
  • Acquired and internally built applications are covered.
  • Changes trigger reassessment.

Step-by-step implementation

1

Understand context

Identify users, data, transactions, exposure, integrations and criticality.

2

Analyze threats and obligations

Use risk assessment, abuse cases, privacy and contractual needs.

3

Write testable requirements

Specify authentication, authorization, validation, logging, encryption, resilience and administration.

4

Prioritize and approve

Assign owner, rationale and acceptance criteria.

5

Trace through delivery

Link requirements to design, backlog, tests and release.

6

Maintain requirements

Update after change, vulnerability, incident and regulation.

What this could look like in practice

A payment application requirement states that high-risk refunds need step-up authentication, independent approval and immutable logging. Test cases verify each condition before release.

ActivityPractical implementationEvidence
Requirement discoveryWorkshops identify assets and abuse cases.Requirements record
SpecificationRequirement includes measurable acceptance criteria.Backlog item
Supplier acquisitionRFP and contract include security needs.Evaluation
ValidationTests link directly to requirements.Traceability matrix

Implementation evidence

  • Security requirements method
  • Application context
  • Threat models
  • Approved requirements
  • Acceptance criteria
  • Supplier evaluations
  • Traceability
  • Test results

Useful metrics

  • High-risk requirements with tests
  • Late security requirement changes
  • Requirements failing acceptance
  • Applications without approved requirements

Common mistakes

  • Using vague phrases such as ‘secure authentication’.
  • Copying a checklist without context.
  • Ignoring administration and logging.
  • Writing requirements after build.
  • Not updating requirements after design change.

Questions an auditor may ask

  • How are requirements derived?
  • Show a testable requirement.
  • How are acquired applications covered?
  • How is traceability maintained?
Implementation test: Choose a high-risk application behavior and trace its threat, approved requirement, design, implementation and passing test.

Continue through Annex A

Explore the growing library of practical guides for all 93 Annex A controls.

Open the ISO 27001 Annex A Control Library

This independent educational guide paraphrases the practical intent of the control and does not replace the official ISO standards, professional advice or an organization-specific risk assessment. It is not affiliated with or endorsed by ISO.