Many teams approach Annex A as if it were a checklist they must complete in order from the top down. That’s the wrong impulse, and it’s also not the intent of the standard. ISO 27001 is designed to be most effective for organizations that make control choices based on real risk, not for those that simply implement all 93 in the name of covering their backs.
Annex A is a menu, not a mandate
Appendix A has 93 controls. They span 4 categories, organizational (37), people (8), physical (14), and technological (34). So it’s not surprising that many organizations assume they need to implement everything in order to pass an audit. However, you don’t need to. Clause 6.1.3 explicitly states that you select controls that are relevant to the outcome of your risk assessment and that you exclude the ones that aren’t, provided you document why you made that decision.
To do this properly, you need to know all the options available to you. Start by working from the complete iso 27001 controls list, then remove those that aren’t applicable based on your risk assessment. Organizations skip this step and jump directly to implementing controls that seem like a good idea, all too often over-engineering things that don’t matter in their environment and under-resourcing the things that do.
The two-sided test for including a control
There are just two valid reasons to add a control from Annex A. One, a stakeholder requirement forces your hand – a client contract, a regulation, a legal obligation per clause 4.2. Two, the control mitigates a risk your risk assessment identified as unacceptable to tolerate.
If a control doesn’t pass either of those tests, its exclusion goes on the Statement of Applicability with an explanation. Not a void. Not a guess that it’s a no-brainer. An auditor from your certifying body will ask for that rationale, and “we didn’t think we had to” doesn’t count.
The tailoring workflow, start to finish
Adapting isn’t a one-time choice made in a spreadsheet. It’s a process, and when steps are missed that’s where most non-conformities originate.
First, provide context. The requirement in Clause 4 to determine the organization’s context – internal issues, external issues, interested parties – is not just a paperwork exercise. It establishes the framework for everything that follows. From there, run your risk assessment with the methodology your organization chose to adopt. Your results should identify a list of risks ranked and linked to specific assets, based on what you’ve learned from your asset management process and the actual threats you face – be it ransomware, insiders, supply-chain, etc.
Then, for each of those identified risks, link the applicable controls from Annex A. Next, evaluate. Not every control needs to be cranked up to 11 everywhere – the level should increase based on asset criticality and your organization’s tolerance for the risk. A control for a system holding customer data that’s subject to multiple regulations will require a different approach than a system that hosts your lunch menu.
Add those into the Statement of Applicability and make sure your selected implementations are part of the risk treatment plan. The business owners of the risks will need to provide approval of the risk they are not willing to treat. It’s their feedback that helps justify the tailoring decision.
A gap analysis run before you start this process is worth the time. It shows where you are not meeting the standard’s baseline expectations and ensures your risk assessment is real, not based on esoteric considerations.
What good tailoring actually looks like
A cloud-native startup that doesn’t really have any offices might concentrate its efforts on access management and technological controls while reducing physical security controls to something appropriate – because there is less physical attack surface to protect.
A manufacturing company that runs operational technology on the shop floor is going to have the opposite priority. Physical controls and operational safeguards matter more there than cloud-specific technological controls, because that is where the real exposure sits.
Neither company is cheating. They’re both putting effort where the risk assessment says it belongs, and they can both defend their Statement of Applicability to an auditor with a straight face.
The controls you shouldn’t touch
There are some controls that you would struggle to justify ever dropping, no matter how low your risk appetite might be. Controls around leadership commitment, asset management, access control, and incident response fall into this category. If you remove one of these, you leave a hole so big an auditor could walk through it, because these controls hold the management system together. Tailoring is about proportional effort, not about removing the foundation.
Getting this right pays off at audit time
What auditors really seek is an organization where you can clearly see why each control was or wasn’t selected based on risk, and where the gaps inspire confidence, not suspicion. Build your Statement of Applicability as an honest record of decisions you can defend, not as a document written to look thorough, and the audit takes care of itself.
