A.8.26 — Application Security Requirements

The procurement team selects a new HR application based on features and price. Nobody asks about encryption at rest, session management or API security. After deployment, a penetration test reveals that the application stores passwords in plain text and has no CSRF protection. A.8.26 requires that security requirements are identified and addressed before development or acquisition begins.

This control bridges the gap between business needs and technical implementation. It ensures that every application — developed internally, custom-built by a supplier or purchased off the shelf — meets defined security standards.

Purpose: Ensure all information security requirements are identified and addressed when developing or acquiring applications.
Control type: Preventive
Security objectives: Confidentiality, Integrity, Availability
Theme: Technological
BSI modules: CON.8, APP.6, APP.7, OPS.1.1.6, CON.10
KPI: Percentage of applications with documented and verified security requirements

Responsible	IT Security Officer
Accountable	Information Security Officer / (C)ISO
Consulted	Asset Owner, Data Protection Officer, Department Head, IT Administrator, IT Security Officer, Legal Counsel, Process Owner, Software Developer / Architect, Software Development Lead, Supply Chain Manager
Informed	Asset Owner, Department Head, Head of IT, IT Security Officer, Internal Auditor, Legal Counsel, Project Manager, Software Developer / Architect, Supply Chain Manager, Top Management

What does the standard require?

Identify security requirements. For every application, define security requirements covering authentication, authorization, data protection, resilience and compliance.
Specify formally. Document requirements in a format that developers and testers can verify.
Approve requirements. Ensure security requirements are reviewed and approved by relevant stakeholders.
Address transactional services. Applications processing transactions need additional protections: integrity, non-repudiation and cryptographic safeguards.
Verify compliance. Test that implemented applications actually meet the specified requirements before going live.

In practice

Integrate security requirements into project initiation. Every new application project or major change starts with a security requirements analysis. Use OWASP ASVS (Application Security Verification Standard) as a structured framework for defining requirements by verification level.

Include security in procurement evaluations. When purchasing software, add security requirements to the RFP. Require vendors to demonstrate compliance through documentation, certifications or independent test results.

Document and track requirements. Record security requirements alongside functional requirements in the project’s requirements management tool. Link each requirement to its verification method (code review, automated test, penetration test).

Verify before go-live. Conduct a security assessment (or require one from the vendor) before deploying any new application. Map test results to the documented security requirements to confirm coverage.

Typical audit evidence

Auditors typically expect the following evidence for A.8.26:

Security requirements documents — formal requirements for each application (see Secure Software Development Policy in the Starter Kit)
Requirements approval records — evidence of stakeholder sign-off
Procurement security evaluations — security criteria used in vendor selection
Verification results — test reports mapping to security requirements
Transaction protection evidence — cryptographic controls for transactional services

KPI

Percentage of applications with documented and verified security requirements

Measured as a percentage: how many of your applications have documented security requirements with verification evidence? Target: 100% for applications processing sensitive data.

Supplementary KPIs:

Percentage of new projects with security requirements defined before development
Number of security requirements gaps found during pre-go-live testing
Percentage of purchased applications evaluated against security criteria

BSI IT-Grundschutz

A.8.26 maps to BSI development and application modules:

CON.8 (Software Development) — requirements for defining security requirements during the development process.
APP.6 (General Software) — security evaluation requirements for acquired software.
CON.10 (Developing Web Applications) — specific security requirements for web applications.

A.8.25 — Secure Development Life Cycle: The SDLC framework where security requirements are implemented.
A.8.29 — Security Testing in Development and Acceptance: Testing that verifies security requirements are met.
A.8.30 — Outsourced Development: Security requirements for externally developed applications.

Sources

ISO/IEC 27001:2022 Annex A, Control A.8.26 — Application security requirements
ISO/IEC 27002:2022 Section 8.26 — Implementation guidance for application security requirements
BSI IT-Grundschutz, CON.8 — Software Development

Frequently asked questions

When should security requirements be defined?

During the requirements and design phase — before development begins. Security requirements defined after development is complete are expensive to implement and easy to miss.

Does A.8.26 apply to purchased software?

Yes. When acquiring applications, security requirements should be part of the evaluation criteria and purchase contract. Verify that the product meets your requirements before deployment.

What are transactional service requirements?

Applications that process financial transactions, e-commerce orders or legally binding actions need additional protections: non-repudiation, transaction integrity, cryptographic protection of transaction data and protection against replay attacks.