If you have been working with ISO 27001 for a few years, you’ll know that the 2022 update was more than just a fresh coat of paint. It was a complete structural reimagining designed to reflect how we actually build and buy technology today. One of the most important shifts for anyone involved in software development or procurement is Annex A 8.26: Application Security Requirements.
In the 2013 version, the focus was often narrow and specific. In 2022, the standard has broadened its horizons, treating application security as a fundamental technical pillar rather than an edge case. Let’s dive into what has actually changed and how it impacts your compliance.
Table of contents
The Shift from 14.1.2 and 14.1.3 to 8.26
In the ISO 27001:2013 standard, application security requirements were primarily found under controls 14.1.2 (Securing application services on public networks) and 14.1.3 (Protecting application services transactions). As those titles suggest, the 2013 version was very concerned with “public networks” and “transactions”, think web shops and public-facing portals.
The 2022 update has merged these and expanded them into Annex A 8.26. It is now categorised as a Technological control. According to Hightable.io, the most significant change here is the scope. The standard no longer just cares about applications that touch the public internet; it cares about all applications. Whether it’s an internal HR tool, a cloud-based SaaS platform, or a custom-built mobile app, the requirements now apply across the board.
What is New in the 2022 Requirements?
The 2022 version is much more explicit about the “what” and the “when” of security. It demands that security requirements are identified, specified, and crucially approved before development starts or a purchase is made. This is the heart of “Security by Design.”
The updated guidance in ISO 27002:2022 provides a much richer list of what these requirements should actually look like. They now include:
- Input Validation and Integrity: Ensuring that data entered into the system is checked to prevent common attacks like SQL injection.
- Encryption and Data Protection: Being specific about how data is protected when it’s sitting in a database (at rest) and when it’s moving between systems (in transit).
- Authentication and Access: Moving beyond just “passwords” to specify needs for Multi-Factor Authentication (MFA) and granular access controls.
- Non-repudiation: For transactional services, ensuring there is a technical way to prove that a specific user performed a specific action, such as using digital signatures.
The “Build vs. Buy” Distinction
One of the most practical changes in Annex A 8.26 is the recognition that most modern companies don’t build everything themselves. As noted by Hightable.io, the 2022 version forces you to apply these requirements to acquired software just as strictly as to in-house code.
In the 2013 era, many organisations bypassed these controls for third-party SaaS because they weren’t “developing” it. Under the 2022 standard, your “requirements” become your due diligence checklist. Before you sign a contract for a new CRM or Project Management tool, you must verify that it meets your documented security requirements. If it doesn’t support the level of encryption or authentication you’ve specified, you technically shouldn’t be buying it. +1
Why the Transition to “Preventive” Matters
Under the new attribute system, Annex A 8.26 is classified as a Preventive control. In the 2013 version, many companies were reactive, fixing security bugs after they were discovered. The 2022 update is designed to stop these vulnerabilities from being created or imported in the first place.
By forcing the business to “approve” security requirements early, the standard ensures that security isn’t just an IT problem; it’s a business decision. If a business owner wants a new feature that bypasses a security requirement, they have to formally sign off on that risk. This creates a much stronger audit trail and moves security from the basement to the boardroom.
Practical Steps for Your Transition Audit
If you are moving from ISO 27001:2013 to the 2022 version, you can’t just copy and paste your old 14.1.2 policy. You need to show the auditor that you have a consistent process for defining requirements. Hightable.io suggests a few key pieces of evidence to prepare:
- A Security Requirements Specification (SRS): This doesn’t have to be a 100-page document, but you need a record (perhaps a Jira ticket or a spreadsheet) showing that for every new software project, security needs were considered.
- Third-Party Risk Assessments: Evidence that you’ve checked your SaaS vendors against your internal security requirements before onboarding them.
- Business Owner Approval: Proof that the people paying for the software or the development have actually seen and approved the security specifications.
Conclusion
Annex A 8.26 is a perfect example of how ISO 27001 has matured. By moving away from a narrow focus on “public networks” and “transactions,” the 2022 update acknowledges that in a modern digital business, every application is a potential risk. Whether you are building in-house or buying off-the-shelf, 8.26 requires you to put security at the very beginning of the journey.
By following the updated guidance and utilizing structured resources like Hightable.io, you can ensure that your application stack isn’t just a collection of tools, but a secure foundation that supports your organisation’s growth.