In this guide, I will show you exactly how to implement ISO 27001 Annex A 8.26 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.
I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.
Key Takeaways: ISO 27001 Annex A 8.26 Application Security Requirements
ISO 27001 Annex A 8.26 mandates that security is not an afterthought. Whether you are building software in-house or buying an off-the-shelf tool (SaaS), you must identify, specify, and approve security requirements before the project starts. It prevents the costly mistake of realizing a new app doesn’t support Single Sign-On (SSO) or encryption after you’ve already bought it.
Core requirements for compliance include:
- The “Shopping List” Approach: Before you write a line of code or sign a contract, you must create a list of non-negotiable security features (e.g., “Must support MFA,” “Must encrypt data at rest,” “Must have audit logs”).
- Buy vs. Build: This control applies to both.
- Build: Developers need security requirements in their tickets/stories (e.g., “As a user, my password must be salted and hashed”).
- Buy: Procurement teams need a security checklist to vet vendors (e.g., “Does this SaaS provider have ISO 27001?”).
- Transactional Security: If the application handles payments or sensitive transactions, you must specify extra protections like fraud detection and non-repudiation.
- Legal Compliance: You must verify that the app meets regulatory needs (like GDPR or PCI DSS) before acquisition.
Audit Focus: Auditors will ask to see your Requirements Document (or Jira User Stories). They want to check:
- Traceability: “Show me the ticket where you required ‘MFA’ for this new login portal.”
- Vendor Vetting: “Show me the security questionnaire you sent to Salesforce/Slack before you signed the contract.”
- Approval: “Who signed off that these requirements were met?”
Common Application Security Requirements (The Checklist):
| Category | Requirement Example | Why it matters |
|---|---|---|
| Identity | “Must support SAML/SSO integration.” | Centralizes user management; prevents weak passwords. |
| Data Protection | “All exports must be encrypted.” | Prevents data leaks if a file is stolen. |
| Logging | “Must log all failed login attempts.” | Allows you to detect brute-force attacks. |
| Session Mgmt | “Session must timeout after 15 mins.” | Prevents unauthorized access on shared devices. |
| Input Validation | “Forms must reject special characters.” | Prevents SQL Injection attacks. |
Table of contents
- Key Takeaways: ISO 27001 Annex A 8.26 Application Security Requirements
- What is ISO 27001 Annex A 8.26?
- ISO 27001 Annex A 8.26 Explainer Video
- ISO 27001 Annex A 8.26 Podcast
- ISO 27001 Annex A 8.26 Implementation Guidance
- How to implement ISO 27001 Annex A 8.26
- ISO 27001 Annex A 8.26 Implementation Checklist
- ISO 27001 Annex A 8.26 Audit Checklist
- Applicability of ISO 27001 Annex A 8.26 across different business models.
- Fast Track ISO 27001 Annex A 8.26 Compliance with the ISO 27001 Toolkit
- Conclusion
- ISO 27001 Annex A 8.26 FAQ
- Related ISO 27001 Controls
- Further Reading
- ISO 27001 Annex A 8.26 Control and Attributes Table
What is ISO 27001 Annex A 8.26?
ISO 27001 Annex A 8.26 is about application security requirements which means you need to identify what your requirements are and show they were implemented and approved.
ISO 27001 Annex A 8.26 Application Security Requirements is an ISO 27001 control that requires us to identify, specify and approve information security requirements when we develop or acquire applications.
ISO 27001 Annex A 8.26 Purpose
ISO 27001 Annex A 8.26 is a preventive control to ensure all information security requirements are identified and addressed when developing or acquiring applications.
ISO 27001 Annex A 8.26 Definition
The ISO 27001 standard defines ISO 27001 Annex A 8.26 as:
Information security requirements should be identified, specified and approved when developing or acquiring applications.
ISO27001:2022 Annex A 8.26 Application Security Requirements
ISO 27001 Annex A 8.26 Explainer Video
In this beginner’s guide to ISO 27001 Annex A 8.26 Application Security, ISO 27001 Lead Auditor Stuart Barker and his team talk you through what it is, how to implement in and how to pass the audit. Free ISO 27001 training.
ISO 27001 Annex A 8.26 Podcast
In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001:2022 Annex A 8.26 Application Security Requirements. The podcast explores what it is, why it is important and the path to compliance.
ISO 27001 Annex A 8.26 Implementation Guidance
Whilst I am a software engineering degree educated and time served professional, I am not in the business of telling you how to develop either systems or software. These are professions in their own right. Time has moved on. What I am going to do is show you want the ISO 27001 standard expects in the implementation for you to achieve ISO 27001 certification. These are on the whole, no brainers, common sense and what you would expect but let us take a look anyway.
Secure Development Policy
If you are developing software then the first step is to create, or download, your secure development policy. The secure development policy set’s out what you do for information security in the context of software and systems development. It does not set out how you do it, as how you do it is covered in your processes.
The ISO 27001 Template is the quickest way to do this but you can also take a look and write it yourself.
Identifying and Specifying Application Security Requirements
The requirements of the application security are going to be specific to you but the standard makes recommendations on what to consider and decide if applicable or not. From this list, and others, choose what is applicable and be in a position to defend if something is on the list and you do not have it, why you do not have it.
- Access Control
- Information Classification
- Segregation of Duty and Access
- Resilience such as ability to repel malicious attacks
- Legal, regulatory and contractual Requirements
- Privacy
- Data Protection
- Protection of data that is processed, stored or transmitted
- Input Validation
- Output Validation
- Use and Restrictions on ‘open text’ fields allowing unrestricted input
- Logging and Monitoring
- Non Reputation
- The requirements of other Annex A controls on your Statement Of Applicability (SOA)
Transactional Services
Additional guidance is given for consideration in situations where you have applications that offer transactional services between organisations and partners.
Those requirements include the above and in addition:
- Authorisation Processes and Levels
- Non Repudation
- Physical Transfers of Media and Documents
- Data Retention Periods
- Insurance
- Contractual Requirements
- End of Contract / Relationship
Payment and Ordering Applications
Payments on card are covered under the PCI DSS so if this is something you do then this is a standard that will apply and be checked as being in place.
You should follow all legal and regulatory requirements for this kind of data and this is covered extensively in laws and regulations. Seek the help of a legal professional if you are unsure to understand what those requirements are.
From an ISO27001 perspective the appropriate implementation of cryptography will be considered but know that requirements are greater than ISO27001 in this space.
How to implement ISO 27001 Annex A 8.26
Implementing application security requirements ensures that security is a core component of the software development lifecycle rather than an afterthought. By following these technical steps, organisations can satisfy ISO 27001 Annex A 8.26 requirements and build resilient applications that protect sensitive data by design.
1. Identify Legal, Regulatory and Business Requirements
- Determine all applicable statutory and regulatory obligations, such as the UK GDPR or PCI DSS, that influence how the application handles data.
- Document specific business requirements for data availability and integrity to ensure the application meets operational uptime targets.
- Result: A comprehensive compliance baseline that dictates the minimum security features required for the application.
2. Execute Application Threat Modelling
- Conduct structured threat modelling sessions using frameworks like STRIDE to identify potential entry points and attack vectors.
- Develop Data Flow Diagrams (DFDs) to visualise how sensitive information moves through the application and identify where encryption is mandatory.
- Result: A proactive identification of architectural weaknesses that allows for the mitigation of risks before any code is written.
3. Define Technical Security Controls and IAM Roles
- Specify mandatory technical requirements for Identity and Access Management (IAM), including Multi-Factor Authentication (MFA) and granular Role-Based Access Control (RBAC).
- Establish requirements for secure session management, such as the use of secure cookies, absolute session timeouts and the rotation of session tokens.
- Result: A robust authentication framework that prevents unauthorised access and limits the blast radius of potential credential compromises.
4. Mandate Input Validation and Cryptographic Standards
- Formalise requirements for strict input validation and output encoding to protect the application against SQL injection and Cross-Site Scripting (XSS).
- Define cryptographic standards for data at rest and in transit, specifying the use of industry-standard protocols like AES-256 and TLS 1.3.
- Result: The elimination of common software vulnerabilities and the assurance of data confidentiality throughout the application lifecycle.
5. Integrate Requirements into the CI/CD Pipeline
- Translate security requirements into automated test cases within the CI/CD pipeline to ensure continuous verification of security controls.
- Provision automated Static Application Security Testing (SAST) and Software Composition Analysis (SCA) to flag deviations from defined security requirements.
- Result: Automated enforcement of security standards that prevents non-compliant code from reaching production environments.
6. Finalise a Requirements Traceability Matrix (RTM)
- Create a Requirements Traceability Matrix to map every identified security requirement to a specific design element, code module and test case.
- Obtain a formal sign-off from the Security lead or Data Protection Officer (DPO) confirming that all specified requirements have been met.
- Result: A verifiable audit trail for ISO 27001 auditors demonstrating that security was intentionally engineered into the application.
ISO 27001 Annex A 8.26 Implementation Checklist
Application Security Requirements ISO 27001 Annex A 8.26 Implementation Checklist
1. Secure Coding Practices
Implement secure coding guidelines (e.g., OWASP Top 10) and conduct regular code reviews to minimise vulnerabilities during development.
Developers may lack sufficient training in secure coding practices.
Provide mandatory secure coding training and integrate security checks into the development lifecycle.
2. Input Validation
Ensure all application inputs are validated to prevent injection attacks (e.g., SQL injection, cross-site scripting).
Identifying all potential input points and crafting effective validation rules can be complex.
Employ a combination of whitelisting, blacklisting, and regular expression validation, using automated testing tools where possible.
3. Authentication and Authorisation
Implement robust authentication mechanisms (e.g., multi-factor authentication) and granular authorisation controls to restrict access to sensitive data and functionalities.
Balancing strong security with user experience can be difficult.
Implement role-based access control (RBAC) and consider user-friendly MFA methods like time-based one-time passwords (TOTP).
4. Data Protection
Encrypt sensitive data at rest and in transit using strong cryptographic algorithms.
Key management can be complex and requires careful planning.
Implement a robust key management system (KMS) and follow best practices for key generation, storage, and rotation.
5. Session Management
Implement secure session management mechanisms to prevent session hijacking and other related attacks.
Maintaining session state securely while ensuring performance can be tricky.
Use short session timeouts, regenerate session IDs after login, and employ secure cookies.
6. Error Handling
Implement proper error handling to avoid revealing sensitive information to attackers.
Developers may inadvertently expose sensitive data in error messages.
Implement generic error messages and log detailed error information securely for later analysis.
7. Logging and Monitoring
Implement comprehensive logging and monitoring of application activity to detect and respond to security incidents.
Analysing large volumes of log data can be overwhelming.
Use Security Information and Event Management (SIEM) systems to automate log analysis and alert on suspicious activity.
8. Vulnerability Management
Conduct regular vulnerability scanning and penetration testing to identify and remediate security weaknesses in applications.
Keeping up with the latest vulnerabilities and patching them promptly can be resource-intensive.
Prioritise patching based on risk and implement a robust vulnerability management process.
9. Application Security Testing
Integrate security testing (e.g., static and dynamic analysis) into the software development lifecycle (SDLC).
Integrating security testing into the SDLC can slow down development.
Automate security testing as much as possible and train developers on how to address security issues early in the development process.
10. Third-Party Components
Ensure that any third-party libraries or components used in applications are secure and up-to-date.
Tracking and managing vulnerabilities in third-party components can be difficult.
Use software composition analysis (SCA) tools to identify and manage vulnerabilities in third-party components and establish a process for patching them promptly.
ISO 27001 Annex A 8.26 Audit Checklist
Application Security Requirements ISO 27001 Annex A 8.26 Audit Checklist
1. Secure Coding Practices
Verify that secure coding guidelines (e.g., OWASP Top 10) are defined, communicated, and followed by developers.
Review secure coding standards documentation, examine code samples for adherence, interview developers about their understanding and application of secure coding practices, and perform static code analysis.
2. Input Validation
Check if input validation is implemented for all application inputs to prevent injection attacks.
Review application documentation, examine code for input validation routines, perform penetration testing to attempt injection attacks, and review vulnerability scanning reports related to input validation.
3. Authentication and Authorisation
Assess the strength of authentication mechanisms and the effectiveness of authorisation controls.
Review authentication and authorisation policies, examine configuration settings for authentication systems, perform penetration testing to attempt unauthorised access, and review user access logs.
4. Data Protection
Verify that sensitive data is encrypted at rest and in transit.
Review data encryption policies, examine database and network configurations, review key management procedures, and perform vulnerability scans to check for unencrypted data.
5. Session Management
Check the implementation of secure session management mechanisms.
Review session management policies, examine application code for session management routines, perform penetration testing to attempt session hijacking, and review session timeout configurations.
6. Error Handling
Verify that error handling practices do not reveal sensitive information.
Review error handling procedures, examine application code for error handling routines, perform testing to trigger errors and observe the information displayed, and review application logs for sensitive data exposure in error messages.
7. Logging and Monitoring
Assess the comprehensiveness of logging and monitoring of application activity.
Review logging and monitoring policies, examine log configuration settings, review security information and event management (SIEM) system configurations, and analyse log data for suspicious activity.
8. Vulnerability Management
Verify that regular vulnerability scanning and penetration testing are conducted and that identified vulnerabilities are remediated.
Review vulnerability scanning and penetration testing schedules and reports, examine vulnerability remediation records, and interview IT staff about the vulnerability management process.
9. Application Security Testing
Check if security testing is integrated into the software development lifecycle (SDLC).
Review the SDLC documentation, examine security testing plans and reports, interview developers and testers about their roles in security testing, and observe security testing activities.
10. Third-Party Components
Verify that third-party libraries and components are managed securely.
Review third-party component management policies, examine software composition analysis (SCA) reports, interview IT staff about the process for patching third-party components, and review vulnerability scanning results for third-party components
Applicability of ISO 27001 Annex A 8.26 across different business models.
| Business Type | Applicability | Examples of Control Implementation |
|---|---|---|
| Small Businesses | Primarily applies when purchasing COTS (Commercial Off-The-Shelf) software or SaaS tools. You must define what security features are “non-negotiable” (e.g., MFA support) before signing a contract. |
|
| Tech Startups | Applies to the internal build process. Security requirements must be treated as “Functional Requirements” and added to the product backlog (e.g., Jira tickets) before sprints begin. |
|
| AI Companies | Focuses on the unique requirements of model training and inference. Constraints must be defined regarding data privacy, model inversion risks, and ethical guardrails. |
|
Fast Track ISO 27001 Annex A 8.26 Compliance with the ISO 27001 Toolkit
For ISO 27001 Annex A 8.26 (Application security requirements), the requirement is to identify, specify, and approve security requirements (like encryption, authentication, and input validation) before you build or buy software.
| Compliance Factor | SaaS “Requirements Management” | High Table ISO 27001 Toolkit | Real-World Example |
|---|---|---|---|
| Data Ownership & Continuity | Effectively rents you the “blueprint” for your product’s safety. If you leave, you lose the definitions of your security specs. | Permanent Ownership: You receive the “Application Security Requirements Specification” in Word/Excel, which remains your permanent standard. | Attaching your owned security specs to every vendor contract indefinitely without needing a subscription to view them. |
| Simplicity & Workflow | Overwhelms teams with new logins and complex ticket linking systems that project managers often ignore. | Requirements, Not Tickets: A simple “Security Requirements Checklist” that can be pasted directly into Jira tickets or Statements of Work. | Pasting a checklist into a Jira story for developers rather than forcing them to use a separate “compliance module.” |
| Cost Structure | Often charges based on the number of “assets” or “projects,” creating a “success tax” as your product portfolio grows. | One-Off Fee: A single payment covers the template suite, allowing you to use it for one project or one thousand microservices. | Documenting requirements for a new suite of apps without triggering an upgrade in your compliance software tier. |
| Freedom & Methodology | Enforces specific methodologies (e.g., Waterfall sign-offs) that may clash with modern Agile or DevOps sprint planning. | Method Agnostic: The “Security Requirements List” is adaptable, fitting equally well into formal spec sheets or Agile “Security User Stories.” | Converting the Toolkit’s requirements into “User Stories” for a sprint backlog, fitting your build process perfectly. |
Summary: For Annex A 8.26, the auditor wants to see that you defined security needs before you started coding. The High Table ISO 27001 Toolkit provides the standardised list of requirements you need to satisfy this control instantly, giving you a professional, permanent solution without the bloat of a subscription platform.
Conclusion
There is actually nothing specific in this control that is not covered in other controls. This control basically says, yes, all the other controls apply to applications as well.
It is telling you, just because you are buying applications or building them, don’t discount the wider requirements of Annex A.
ISO 27001 Annex A 8.26 FAQ
What is the primary requirement of ISO 27001 Annex A 8.26?
ISO 27001 Annex A 8.26 requires that information security requirements are identified, specified, and approved when developing or acquiring applications. The goal is to ensure that security is “baked in” from the very start of a project, rather than trying to bolt it on after the software is built or purchased.
When should application security requirements be defined?
Security requirements must be defined during the initial requirement gathering or design phase, before coding or purchasing begins. This “Shift Left” approach saves money and reduces risk. Key milestones include:
- Business Analysis: Defining data sensitivity (e.g., “This app handles PII”).
- Vendor Selection: Checking if a SaaS tool meets your encryption standards before signing the contract.
- Sprint Planning: Including security criteria (like input validation) in user stories.
What are examples of application security requirements?
Requirements should be specific, testable statements regarding how the application protects data. Common examples found in ISO 27001 implementations include:
- Identity: “The application must support Multi-Factor Authentication (MFA).”
- Transactions: “All payment transactions must be encrypted using TLS 1.2 or higher.”
- Logging: “The system must generate an immutable log for every failed login attempt.”
- Session Management: “User sessions must time out after 15 minutes of inactivity.”
Does Annex A 8.26 apply to “Off-the-Shelf” (COTS) software?
Yes, this control applies to any software you introduce into your environment, whether you build it or buy it. For commercial software (COTS) or SaaS:
- You cannot change the code, so you must verify the vendor’s security controls meet your requirements before purchase.
- You must define configuration requirements (e.g., “We require the ability to disable public sharing”).
How do we handle transactions over public networks?
Applications conducting transactions over public networks (like the internet) require stricter controls to prevent fraud and interception. Annex A 8.26 mandates specific requirements for these scenarios, such as:
- Validating the identity of both parties (Mutual TLS or robust AuthN).
- Ensuring non-repudiation (proof that the transaction occurred).
- Protecting the integrity of the transaction data (preventing “Man-in-the-Middle” attacks).
What will an ISO 27001 auditor ask regarding Control 8.26?
Auditors will look for a “Requirements Specification” document or ticket that proves security was considered early. Expect questions such as:
- “Show me the project plan for your new CRM—where are the security requirements listed?”
- “How did you verify this new SaaS tool supported SSO before you bought it?”
- “Do your developers have a checklist of security standards (like OWASP ASVS) they must meet?”
Related ISO 27001 Controls
ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities
ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance
Further Reading
ISO 27001 Logging and Monitoring Policy Beginner’s Guide
ISO 27001 Controls Ultimate Guide
ISO 27001 Annex A 8.26 Control and Attributes Table
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| Preventive | Confidentiality | Protect | Application Security | Protection |
| Integrity | System and Network Security | Defence | ||
| Availability |
