A8.26 Application security requirements

Application security requirements define the security functions, controls, and considerations that must be integrated into applications during design, development, and deployment. These requirements ensure that applications are resilient to common threats like injection attacks, unauthorized access, and data leakage.

ISO 27001 A8.26 Application security requirements mandate organizations to establish and document security requirements for all applications—whether developed in-house, acquired, or cloud-based. These requirements must be based on business needs, regulatory obligations, and known threats.

Implementation Guide #

Step 1: Identify Application Use and Sensitivity

• Classify applications based on the type and sensitivity of data they process (e.g., PII, financial, health data).
• Determine applicable legal, regulatory, and business requirements.
  → Tool Recommendation: Use Microsoft Purview or OneTrust for data classification and compliance mapping.

Step 2: Define Baseline Security Requirements

• Establish minimum security controls required for all applications.
• Base these on known standards like OWASP ASVS (Application Security Verification Standard), ISO/IEC 27034, and NIST.
  → Tool Recommendation: Use OWASP ASVS documentation as a framework to structure your baseline.

Step 3: Embed Security into Functional Requirements

• Ensure requirements include:
  – Authentication and authorization mechanisms
  – Secure session management
  – Input validation and sanitization
  – Secure data storage and transmission
  – Logging and monitoring capabilities
  → Tool Recommendation: Integrate with Jira, Azure DevOps, or Atlassian Confluence to manage and trace requirements.

Step 4: Perform Threat Modeling and Risk Assessment

• Conduct threat modeling for critical applications.
  → Tool Recommendation: Microsoft Threat Modeling Tool, OWASP Threat Dragon
• Document security risks and define specific controls to address them.

Step 5: Define Non-Functional Security Requirements

• Include performance, availability, auditability, and recovery requirements.
• Specify encryption standards, authentication methods, and access controls.

Step 6: Validate and Review Requirements

• Involve stakeholders (security, dev, compliance, legal) in reviewing requirements.
• Update security requirements periodically as threats and regulations evolve.
  → Tool Recommendation: Use Confluence or Notion for collaborative reviews and documentation.

Templates #

• Application Security Requirements Checklist
• Secure Requirements Specification Template
• Threat Modeling Template
• Regulatory Compliance Mapping Sheet
• Security Requirements Traceability Matrix (SRTM)

Example #

A healthcare software company was developing a patient portal to handle medical records. They began by classifying the application under HIPAA-regulated systems, applied OWASP ASVS Level 2 as their baseline, and used Microsoft Threat Modeling Tool to uncover risks like unauthorized data access. Security requirements such as strong multi-factor authentication, audit logging, and encrypted data transmission were integrated into their Jira tickets to track development. As a result, the application passed both internal audits and external HIPAA compliance assessments.

How to Comply #

To comply with ISO 27001 A.8.26, organizations should:

• Define security requirements early in the application lifecycle.
• Use standardized frameworks and methodologies (e.g., OWASP ASVS, ISO 27034).
• Align requirements with the data classification and threat landscape.
• Continuously review and update application security requirements.
• Ensure requirements are traceable and testable.

How to Pass an Audit #

Key Documents to Prepare:

• Application Security Requirements Document
• Risk Assessments and Threat Models
• Functional and Non-functional Security Specs
• Mapping to OWASP or ISO Standards
• Stakeholder Review Logs

What the Auditor Will Check:

• Are documented security requirements defined and applied?
• Are the requirements based on risk and data sensitivity?
• Is there a traceable link between requirements and implementation/testing?
• Are frameworks like OWASP ASVS being used to standardize application security?

Top 3 Mistakes People Make #

• Defining security requirements too late in the development process.
• Using vague or generic security requirements not aligned to actual risk.
• Failing to revisit and update security requirements as systems evolve.

ISO 27001 Application Security FAQ #

Q1: Are security requirements needed for commercial off-the-shelf (COTS) apps?
Yes—evaluate them against your security needs and document gaps or compensating controls.

Q2: What if we use third-party developers?
Include your security requirements in contracts or SLAs and ensure developers follow them.

Q3: How do I choose the right level of security requirements?
Use a tiered approach like OWASP ASVS Levels (L1–L3), based on the application’s risk level.

ISO 27001 Controls and Attribute Values #

By formalizing and integrating application security requirements, organizations build more secure software, reduce vulnerabilities, and align with compliance frameworks from the ground up.