If you have been managing information security for a while, you know that security is often treated as an afterthought in project management. The ISO 27001 standard has always tried to fix this, but with the release of the 2022 update, the requirements have become much clearer and more structured. One of the most significant areas of focus is Annex A 5.8, which deals with “Information security in project management.”
Previously known as Annex A.6.1.5 in the 2013 version, this control has been moved and refined to fit the new “Organisational” theme of the 2022 update. Let’s take a look at what has changed and how you can ensure your projects remain secure from the drawing board to completion.
Table of contents
The Shift from 2013 (A.6.1.5) to 2022 (A.5.8)
In the ISO 27001:2013 version, this control was tucked away under the “Internal Organisation” section. While it mandated that security should be addressed in project management, it was often criticised for being a bit vague. Many organisations struggled to define exactly how security should be integrated into different types of projects.
In the 2022 version, the control has been renumbered to Annex A 5.8. While the core objective remains the same—ensuring information security is integrated into project management—the 2022 update is more explicit about the need for consistency. According to Hightable.io, the goal here is to ensure that security is not just an occasional consideration but a fundamental part of the project lifecycle, regardless of the project’s nature.
What Does Annex A 5.8 Require?
The updated control requires that information security be integrated into project management from the very beginning. This isn’t just for IT projects; it applies to any project that could impact the security of your information. Whether you are launching a new product, moving offices, or implementing a new HR system, security must be on the agenda.
The 2022 version emphasises several key activities:
- Risk Assessments: You must conduct information security risk assessments at the start of every project and as significant changes occur.
- Defined Responsibilities: It must be clear who is responsible for security within the project team.
- Security Requirements: Security needs must be identified and addressed as part of the project’s objectives.
- Regular Reviews: Security shouldn’t just be checked at the end; it needs to be reviewed throughout the project’s progress.
Why the Integration of Security in Projects Matters
One of the biggest risks to an organisation is “project creep,” where security measures are bypassed to meet tight deadlines. The 2022 version of Annex A 5.8 is designed to prevent this by making security a mandatory deliverable. By integrating security into the project management methodology—whether you use Agile, Waterfall, or Prince2—you ensure that vulnerabilities are identified before they can be exploited.
The transition from the 2013 version to the 2022 version encourages organisations to move away from “bolt-on” security. Instead, it promotes “security by design.” This shift helps in reducing costs, as fixing a security flaw during the design phase is significantly cheaper than trying to patch a live system after a breach has occurred.
How to Implement Annex A 5.8 for the 2022 Standard
To successfully transition to the 2022 version, you need to look at your existing project management framework. You don’t necessarily need to create a brand-new process, but you do need to enhance what you already have.
As Hightable.io points out, documentation is vital for compliance. You should be able to show auditors that security was considered during the initiation phase of your projects. This might include project initiation documents (PIDs) that list security requirements or risk registers that specifically address project-related threats.
Consider creating a “security checklist” for project managers who might not be security experts. This helps them identify when they need to call in the security team. Furthermore, ensuring that project outcomes are tested against security requirements before “Go Live” is a great way to demonstrate that you are meeting the 2022 standards.
Key Differences to Remember
The main difference you will notice when moving from the 2013 to the 2022 version is the level of maturity required. While the 2013 version asked if you considered security in projects, the 2022 version effectively asks how you ensure it is done every single time. It is a shift from a reactive “hope we remembered security” approach to a proactive, systematic integration.
By focusing on Annex A 5.8, you aren’t just ticking a box for an auditor; you are building a more resilient organisation where change and growth don’t come at the expense of safety. In the modern business world, where projects move faster than ever, this integration is more critical than it has ever been.