ISO 27001 Annex A: Avoid Checkbox Compliance and Build a Real ISMS
A useful way of thinking about Annex A when it comes to your ISO 27001 certification is to see it as your organisation’s story, told through controls.
Instead of starting with a focus on ticking off all 93 controls, start by asking what you are actually trying to protect and what you rely on to do that. Annex A then becomes the structured way you describe those decisions including which controls you use, which you adapt, and which genuinely do not fit your environment.
For many teams, this shift changes the tone of the whole project. You are no longer wrestling with a dense list for the sake of it. You are using Annex A to explain, in a clear and ordered way, how your ISMS supports the risks you care about, the services you provide and the obligations you have in Australia. That makes conversations with auditors, boards and customers less about defending every line item and more about walking them through a sensible, risk-based approach that happens to be anchored in ISO 27001.
What Annex A actually does
ISO 27001 Annex A sits alongside the main clauses of the standard and provides a reference list of security controls that organisations can use to treat information security risks. In ISO 27001:2022, Annex A contains 93 controls grouped into four themes:
- organisational
- people
- physical, and
- technological
That structure matters because it helps teams move past the idea that ISO 27001 is only about technical security. A strong ISMS also depends on governance, people, suppliers, physical security and legal obligations, all of which show up in Annex A.
Why teams get stuck in checkbox compliance
This is where many organisations lose momentum. They open Annex A, see a long list of controls, and start trying to complete it.
The problem is that this usually leads to poor decisions. Controls get marked as implemented because there’s a policy somewhere. Others get excluded because it seems like they don’t apply. In some cases, compliance automation tools give a false sense of comfort because the dashboard looks healthy while the underlying control design is still weak.
That is how organisations end up with gaps such as:
-
supplier controls that exist on paper but are not supported by proper vendor review
-
physical controls excluded for remote teams without considering laptops, home offices or cloud hosting
-
legal and privacy controls mapped vaguely without linking them to actual Australian obligations
-
a Statement of Applicability that reads more like a template than a genuine record of risk treatment
None of this usually happens because people are careless. It happens because teams are busy, the control list feels overwhelming, and they want to get audit-ready as quickly as possible.
A better way to use ISO 27001 Annex A controls
The most effective Annex A work starts before you look at the control list.
Begin with your business. Think about the services you provide, the information you hold, the systems you depend on, the suppliers you rely on, and the obligations that apply to you. For Australian organisations, that may include the Privacy Act, contractual security obligations, industry expectations, and in some cases APRA CPS 234 or the ASD Essential Eight.
From there, look at your risks. What would genuinely hurt the business if it went wrong? That is the point where Annex A becomes useful. The controls help you explain how those risks are being managed in a way that is structured, repeatable and defensible in an audit.
In practice, that usually looks like this:
-
Define the risks that matter to your organisation.
-
Map relevant Annex A controls to those risks.
-
Decide whether each control is implemented, adapted, inherited through a supplier, or not applicable.
-
Record that reasoning clearly in the Statement of Applicability.
-
Make sure there is real evidence behind the decision.
That last point matters more than many teams realise. A control is not strong because it exists in a spreadsheet. It is strong because it is operating in a way that makes sense for the organisation and can be evidenced when someone asks questions.
If you are unsure whether your current Annex A mapping reflects the way your organisation actually works, an ISO 27001 gap analysis is usually the best starting point. It gives you a clearer picture of what is already in place, what needs work, and where your documentation may be overstating maturity.
Where the Statement of Applicability fits in
A lot of the value of Annex A shows up in the Statement of Applicability, or SoA.
When it’s done well, the SoA is not just an audit document. It is the bridge between your risk assessment and your control environment. It explains which Annex A controls you’ve selected, how they’re implemented, and why some are not applicable in your environment.
This is one of the first places auditors look when they want to understand whether an ISMS is coherent. If the SoA lines up with the risk assessment, policies, vendor reviews and technical evidence, the story holds together. If it looks generic, inconsistent or over-excluded, that is where the harder questions begin.
This is also why Annex A should never be handled in isolation. The controls only make sense when they are tied back to scope, risk, evidence and the way the business actually operates.
Common Annex A issues seen in practice
A few patterns come up again and again in ISO 27001 projects.
One is over-excluding controls. This is especially common with physical controls in remote-first environments. A team may assume there are no physical risks because they do not run a server room or office, but laptops, screens, home workspaces and third-party data centres still matter.
Another is underestimating supplier risk. Many organisations rely heavily on cloud and SaaS platforms but do not clearly show how supplier due diligence, contractual controls and third-party assurance support their Annex A decisions.
A third is relying too heavily on compliance platforms. Tools like Vanta and Drata can save time, improve evidence collection and make ongoing compliance easier, but they do not replace judgement. Someone still needs to decide whether the controls make sense, whether the risk treatment is appropriate, and whether the SoA reflects reality. That is where experienced guidance makes a real difference.
Siege Cyber works with organisations using Vanta and Drata to help bridge that gap between platform automation and certification-ready implementation. The tooling can do a lot, but it still needs to be paired with sound advice, practical control design and clear audit preparation.
Building an ISMS that works beyond the audit
The best ISO 27001 projects do more than get a certificate. They make security decisions easier.
A well-used Annex A helps teams explain why a control exists, who owns it, what risk it addresses, and what evidence supports it. That is useful in a certification audit, but it is just as useful when a board asks about risk, when a customer sends a due diligence questionnaire, or when an internal team wants to understand why a particular security process matters.
That is the difference between checkbox compliance and a real ISMS. One is built to get through the audit. The other is built to support the way the organisation manages security over time.
How Siege Cyber can help
If your Annex A controls feel disconnected from your actual risks, or your Statement of Applicability is starting to look more like a template than a working document, it may be time to step back and reset the approach.
Siege Cyber helps Australian organisations with ISO 27001 gap analyses, implementation, internal audits and certification preparation. That includes practical support with Annex A control selection, SoA development, evidence review and aligning compliance tooling with real-world security outcomes.
To see how Siege Cyber can help, visit our ISO 27001 consulting page and our compliance pricing page. If you are ready to talk through your current position, contact the team via siegecyber.com.au or email [email protected] to book a consultation.