There is an old carpenter’s adage: “Measure twice, cut once.” In the world of software, this translates perfectly to security. If you wait until an application is fully built to ask, “Is this secure?”, you have already lost the battle. Fixing a security flaw in a finished product is infinitely more expensive and painful than designing it securely in the first place.
ISO 27001:2022 Annex A 8.26, “Application security requirements,” is the control that forces you to measure twice. It requires organizations to identify, define, and approve security requirements before a single line of code is written or a new software contract is signed.
Table of contents
What is the Objective of Annex A 8.26?
The primary goal of this control is to ensure that information security is an integral part of the software lifecycle, not an afterthought. Whether you are developing custom software in-house or buying a SaaS tool from a vendor, you must establish what “secure” looks like for that specific application.
This control mandates that you analyze the risks associated with the application and define specific security controls—such as encryption, authentication, and input validation—to mitigate those risks. It is the foundation of “Security by Design.”
Step-by-Step Implementation Guide
Implementing Annex A 8.26 doesn’t have to be a bureaucratic nightmare. It is simply about asking the right questions at the right time. Here is a practical approach to getting it done.
1. Identify Security Requirements Early
When a new software project is proposed, the discussion usually focuses on features: “It needs to be fast,” “It needs to look good,” or “It needs to integrate with X.” Annex A 8.26 requires you to add “It needs to be secure” to that list.
You must formally document the security requirements alongside the functional requirements. This might include:
- Data Protection: How will sensitive data be encrypted at rest and in transit?
- Access Control: Who can log in? Do we need Multi-Factor Authentication (MFA)?
- Logging: What actions need to be recorded for audit trails?
2. Differentiate Between “Build” and “Buy”
This control applies to all applications, but how you handle them differs:
For In-House Development: You have full control. You need to specify secure coding standards (like OWASP Top 10), define input validation rules to prevent SQL injection, and mandate secure session management.
For Acquired Software (SaaS/COTS): You cannot change the code, but you can change your choice of vendor. Your “requirements” here become your due diligence checklist. Does the vendor hold ISO 27001 certification? Do they support Single Sign-On (SSO)? If they don’t meet your defined requirements, you shouldn’t buy the software.
3. Conduct a Risk Assessment
Not all applications are created equal. A cafeteria menu app does not need the same level of security as a payroll system. You must conduct a risk assessment to determine the criticality of the information processed by the application.
As the experts at Hightable.io point out, this is a preventive control. You are trying to play defence. By assessing the risk early, you ensure that the security measures you demand are proportional to the value of the data you are protecting.
4. Secure Transaction Services
If your application handles payments or sensitive transactions, the standard requires extra rigour. You need to verify the identity of the user, ensuring “non-repudiation” (meaning the user cannot deny they performed the action). This often involves implementing digital signatures, strong encryption protocols, and strict validation of payment details.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
A Quick Checklist for Annex A 8.26
To ensure you are ready for your audit, verify that your application acquisition or development process includes these checks:
- Have security requirements been documented and approved by the business owner?
- Has a risk assessment been performed for the specific application?
- Are there requirements for input validation and output sanitisation?
- Is there a requirement for secure authentication (e.g., MFA)?
- Have you defined how data will be encrypted?
- For external software, have you verified the vendor meets these requirements?
Why This Control Matters
Implementing Annex A 8.26 is the difference between building a fortress and building a house of cards. By defining your security requirements upfront, you avoid costly re-work, protect your user data, and demonstrate to auditors that security is woven into the DNA of your organisation’s technology stack.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
