What Changed Between the 2013 and 2022 Versions? ISO 27001:2022 Annex A 8.4
If your organisation develops its own software, your source code is likely your most valuable intellectual property. In the old ISO 27001:2013 standard, protecting this was handled by Control 9.4.5. However, the 2022 update has modernised this requirement, transforming it into Annex A 8.4: Access to Source Code.
The transition isn’t just about a new number. The way we build software has changed, we use more open-source libraries, automated CI/CD pipelines, and cloud-hosted repositories like GitHub or GitLab. Annex A 8.4 reflects this modern reality, moving beyond simple “restriction” to a more comprehensive “management” approach.
Table of contents
The Structural Shift: From 9.4.5 to 8.4
In the 2013 version, source code protection sat within the “Access Control” domain. In the ISO 27001:2022 revision, it has been moved into the Technological Controls theme. This highlights that while policy is important, the standard now expects technical enforcement as the primary line of defence.
According to Hightable.io, the most noticeable change for many organisations is that the new control explicitly includes development tools and software libraries in its scope. It’s no longer enough to just lock down the code; you have to secure the tools used to write it and the libraries it relies on.
What Exactly is Annex A 8.4?
The core requirement of Annex A 8.4 is that “read and write access to source code, development tools, and software libraries should be appropriately managed.” The goal is to prevent the introduction of unauthorised functionality, avoid malicious or accidental changes, and maintain the confidentiality of your IP.
The 2022 standard expects you to move away from a “free-for-all” development culture. Instead, you need to implement a “need-to-know” and “need-to-use” culture where permissions are granular and auditable.
Key Changes and New Requirements
While the 2013 version was quite brief, the 2022 version adds several specific nuances that you need to address in your updated ISMS:
- Management of Development Tools: This is a major addition. You must now control access to compilers, build tools, and integrated development environments (IDEs). If an attacker can’t change your code but can change your compiler, they can still inject a backdoor.
- Software Libraries: The scope now explicitly covers libraries. With the rise of supply chain attacks, ensuring that developers aren’t pulling in unverified or malicious third-party libraries is a key part of compliance.
- Separation of Read and Write: The 2022 guidance emphasizes that read and write access carry different risks. A developer might need “Read” access to the whole project for context but should only have “Write” access to the specific module they are working on.
- Centralised Administration: The standard strongly suggests using a centralised source code management system (like Git) rather than allowing code to live on individual laptops or unmanaged local servers.
Technical Implementation and Attributes
The 2022 version introduces “Attributes” to help you categorise your controls. For Annex A 8.4, these are:
| Attribute | Value |
|---|---|
| Control Type | Preventative |
| Security Properties | Confidentiality, Integrity |
| Cybersecurity Concepts | Protect |
| Operational Capabilities | Application Security |
Practical Steps for Your Transition
If you are migrating your certification, you should take several practical steps to satisfy the new A 8.4 criteria. As Hightable.io points out, auditors are increasingly looking for “branch protection” and “peer review” as evidence of managed access.
- Inventory Your Repositories: You cannot secure what you don’t know exists. Map out where all your code, libraries, and build tools are hosted.
- Enforce MFA: Multi-factor authentication is now a baseline expectation for any access to source code or development environments.
- Protect the “Master” Branch: Implement branch protection rules so that no single person can push code directly to production without a peer review and approval.
- Secure the Build Pipeline: Ensure that your CI/CD tools (like Jenkins, CircleCI, or Azure DevOps) have their own strict access controls.
Why the Change Matters
The move to Annex A 8.4 is a direct response to the increase in software supply chain attacks. By expanding the control to include tools and libraries, ISO 27001:2022 ensures that your security covers the entire development lifecycle, not just the final product. It forces organisations to treat their development environment with the same level of security rigour as their production environment.
Final Thoughts on Annex A 8.4
The transition from 9.4.5 to 8.4 is an opportunity to move from a manual, policy-based approach to a modern, technical one. By implementing robust version control, granular permissions, and mandatory peer reviews, you aren’t just ticking a box for an auditor, you are significantly reducing the risk of a catastrophic data breach or IP theft.
As Hightable.io highlights, the key to passing your 2022 audit is proof. Ensure your source code management system is generating logs that show who accessed what, when they did it, and who approved their changes.