ISO 27001:2022 Annex A 8.26: Securing Your Application Lifecycle
In the rush to release new features or acquire the latest software tools, security often takes a backseat to functionality. We’ve all seen it happen: a project is 90% complete, and suddenly someone asks, “Wait, how are we handling user passwords?” This “build first, secure later” approach is exactly what ISO 27001:2022 Annex A 8.26 is designed to prevent.
This control, titled Application Security Requirements, isn’t just for software houses writing code from scratch. Whether you are developing a bespoke internal tool, customising an e-commerce platform, or simply buying an off-the-shelf SaaS product, this control mandates that you identify your security needs before you commit to the project.
Table of contents
What is Annex A 8.26?
At its core, Annex A 8.26 is a preventive control. It requires organisations to identify, specify, and approve information security requirements during the initial phases of developing or acquiring applications. Ideally, this happens during the requirements gathering phase—long before a line of code is written or a contract is signed.
The objective is straightforward: ensure that the application (and the data it processes) remains secure by design. This replaces and consolidates some of the older controls regarding security analysis and specification from the 2013 version of the standard.
Why is This Control Critical?
Applications are often the primary gateway to your most sensitive data. If you don’t define what “secure” looks like for a specific application, you are leaving the door open for vulnerabilities. Implementing this control helps you:
- Reduce Remediation Costs: Fixing a security flaw during the design phase is significantly cheaper than patching it in production.
- Ensure Compliance: Many regulations (like GDPR or PCI DSS) require specific security measures (e.g., encryption) that must be planned for.
- Protect Reputation: It ensures that the software you put in front of customers or employees doesn’t become a liability.
For a broader view of how this fits into your Information Security Management System (ISMS), resources like ISO27001.com offer a good overview of the full control set.
Key Requirements to Consider
While every application is different, the standard expects you to consider a specific set of security properties. You shouldn’t just guess; you should have a structured process to determine which of the following apply:
1. Robust Access Control
How will users log in? You need to define requirements for authentication (e.g., is Multi-Factor Authentication required?) and authorisation (e.g., Role-Based Access Control). You also need to decide how the application will handle session management to prevent hijacking.
2. Data Protection & Cryptography
If the application handles sensitive data (PII, financial records), you must specify how that data is protected. This usually involves defining encryption standards for data at rest (stored in the database) and data in transit (moving over the network).
3. Input Validation
One of the most common ways attackers breach applications is by feeding them “bad” data (like in SQL injection attacks). Your requirements should specify that all input must be validated and sanitised. This applies to public-facing forms, API endpoints, and even internal data feeds.
4. Logging and Monitoring
You cannot defend what you cannot see. The application needs to generate logs that allow you to detect suspicious activity. Requirements should specify what events need to be logged (e.g., failed login attempts, access to sensitive records) and where those logs are stored.
5. Resilience and Availability
Security isn’t just about secrecy; it’s about availability too. You should define requirements for the application’s uptime and its ability to resist attacks, such as Denial of Service (DoS) attempts.
Acquisition vs. Development
A common misconception is that this control only applies if you have a team of developers. That is incorrect. It applies equally when you are acquiring software.
When you buy a software package, you should use these requirements as a checklist for your due diligence. If a vendor cannot meet your specified requirements for encryption or Single Sign-On (SSO), that is a risk you need to formally accept or use to disqualify the vendor.
Transactional Services
If your application handles transactions (especially over public networks like the internet), the scrutiny must be higher. You need to ensure the integrity of the transaction—meaning the data cannot be altered in transit—and the validity of the parties involved (authentication). This is vital for preventing fraud and ensuring trust.
How to Demonstrate Compliance
To satisfy an auditor, you need evidence that you didn’t just wing it. This typically looks like:
- Functional Specifications: Documents where security requirements are explicitly listed alongside business requirements.
- Risk Assessments: Showing that you assessed the risks associated with the application to determine the necessary controls.
- Approval Records: Sign-offs from management or security stakeholders confirming that the requirements are adequate.
- Testing Results: Evidence that the final product was tested against these specific requirements (linking to Annex A 8.29 – Security testing in development and acceptance).
Conclusion
ISO 27001 Annex A 8.26 is about being proactive. By formally identifying your application security requirements upfront, you move away from a reactive “patch-it-later” mindset to a mature, secure-by-design culture. It safeguards your data, saves money in the long run, and ensures that your technology assets are assets, not liabilities.
