ISO 27001
ISO 27001 is usually presented as a certificate to obtain. It is more useful to read it as a management system to run, and the difference between those two readings decides whether the investment pays off or simply produces documentation.
This page covers the three decisions that determine the outcome of an ISO 27001 project: the scope, the statement of applicability, and what you do with internal audit.
In many projects the statement of applicability is produced near the end, assembled from the controls that were implemented. That reverses the logic. The document is meant to record which controls apply to your organization, why, and on what grounds others were excluded. Written at the start, it is the instrument that connects your risk assessment to everything you subsequently build.
Written at the end, it becomes a summary of what happened to be done, which is a different document with the same name. Auditors notice the difference quickly, because the justifications refer to decisions nobody can reconstruct. Boards notice it later, when the certificate is in hand and nobody can explain why a particular risk was accepted.
Scope determines how much work the system creates for the rest of its life. Draw it too wide and you are maintaining evidence for parts of the organization that carry no real information risk, indefinitely. Draw it too narrow and the certificate answers a question nobody asked, which becomes obvious the first time a client reads the scope statement on it.
Our test is a straightforward one. Compare the proposed scope to what you contractually promise your clients about how their information is handled. If the promise is broader than the scope, the certificate will not support the promise, and that gap is the one most likely to surface in a client audit or a tender.
Internal audit is often treated as a rehearsal for the certification audit, run shortly beforehand with the aim of finding nothing. That wastes the only mechanism in the standard designed to tell you the truth about your own organization while it is still cheap to act on it.
An internal audit that reports no findings is not good news. It usually means the scope of the audit was set to match what was known to be in order. We work the other way round, and we say so to the board in advance: the purpose is to find what does not work yet, in a year in which that can still be fixed without consequence.
For organizations subject to the Belgian cybersecurity framework, an ISO 27001 certification is an accepted route towards demonstrating conformity. It is not automatic. What is expected is the certification scope, the statement of applicability mapped onto the applicable key measures, and the most recent internal audit report.
That expectation says something about how the three documents should be built in the first place. A scope drawn without the mapping in mind, or a statement of applicability written as a closing formality, will not carry the weight it needs to carry here. Our page on CyFun and assurance levels explains which level that mapping has to answer to.
The standard does not prescribe a volume of documentation. It asks for a system that fits the organization and demonstrably works. Mid-sized organizations run into trouble when they adopt a structure designed for a multinational, because maintaining it requires a function they do not have and were never going to hire.
A system that is slightly smaller than the template but genuinely maintained is worth considerably more, both at the audit and in the years between audits, than a complete set of policies nobody reads. That judgement is the part we bring, and it is the part that decides whether the second year costs half of the first or twice as much.
Before commissioning a gap analysis, write down which part of the organization the system is meant to cover and hold it against your client commitments and your regulatory position. If those three do not line up, no amount of implementation work will make them, and the cheapest moment to notice is now.