ISMS governance
Without a clear scope, classification and SoA, the rest of the program drifts. We define who decides, what sits in the ISMS, how information is classified, and which controls apply.
What we see too often
In our engagements, the ISMS too often starts with copied policies. The real gap sits higher: nobody decided what is in scope, how information is classified, or which controls actually apply.
- a scope statement that is too broad, or exclusions with no justification
- leadership that “supports security” without roles, review or a dated signature
- no classification, so access and suppliers are managed by feel
- an SoA copied from the 93 controls, or never tied to risks
- scattered evidence: nobody knows who decides, or when you review
What this module is
ISMS governance is not a decorative org chart. It is the frame that says: here is the context, here is what the system covers, here is who decides, here is how information is classified, here is which Annex A controls apply and why.
Without that frame, every other module improvises. Risk analysis has no boundary. Policies do not know who they address. The auditor starts with scope: if it drifts, the rest of the file drifts with it.
Where this sits in ISO 27001
This module anchors clauses 4 (context and scope), 5 (leadership and roles) and the Statement of Applicability tied to Annex A. It is not a copy of the 93 controls: it is your documented choice, linked to risks.
Scope and context
We define what the ISMS covers: sites, processes, systems, critical suppliers. Every exclusion is justified. This is what the certification body will read first.
Information classification
We define simple levels (for example public, internal, confidential) and rules for labelling, sharing and retention. Without classification, access control and suppliers stay vague.
Statement of Applicability (SoA)
The SoA states which Annex A controls apply, which are excluded, and why. It links risks, treatments and evidence. It is not a copy of 93 controls: it is your documented choice.
What this module includes
- Context, interested parties and issues (clause 4)
- ISMS scope, inclusions and justified exclusions
- Leadership roles and key responsibilities
- Information classification scheme
- Statement of Applicability (SoA) tied to risks
How we work
Context and interested parties
Workshop with leadership: business issues, demanding clients, legal duties, critical suppliers. We write what actually weighs, not a generic list.
Scope and classification
We delimit sites, processes, systems and justified exclusions. We set simple classification levels, with labelling, sharing and retention rules an SMB can follow.
SoA tied to risks
Each Annex A control gets a status: applicable, excluded, and why. We link that to risks and evidence, not to an orphan spreadsheet.
Roles, signatures and review
RACI, who signs what, how often you review. Leadership validates scope and the SoA. Without a date and a name, it is not governance.
What you receive
- ISMS scope statement, with justified exclusions
- Information classification matrix
- Statement of Applicability (SoA) for retained controls
- RACI chart of security roles
Who it is for
Organizations starting ISO 27001, or whose scope and SoA were never decided by leadership.
Who it is not for
This module is not for an organization that only wants “Word policies”. It is not an internal audit either, nor the drafting of every topic policy.
Typical duration
2 to 4 weeks, in parallel with an initial risk analysis.
What you need to provide
You provide the real org chart, the list of systems and sites, client contracts that require ISO 27001, and 2 to 3 people who know critical processes. Leadership must be available to decide.
What this module does not cover
This module sets the governance frame. It does not write every topic policy and does not perform the internal audit.
Frequently asked questions
- Why group scope, classification and the SoA?
- Because the three pieces hold together. A fuzzy scope produces a decorative SoA. Missing classification weakens access and supplier work.
- Can we exclude a cloud service from scope?
- Sometimes, if the justification holds. Often the supplier stays in scope through supplier management. We decide with you, not to decorate the file.
- Must the SoA cover all 93 controls one by one?
- Yes, each control has a status. No, that does not mean 93 projects. Non-applicable controls are excluded with a reason; the rest are grouped in your modules.
- Can we buy only this module?
- Yes. Each module is sold separately. You do not have to buy the full programme. The pre-assessment remains the most efficient entry point if you do not yet know where to start.
- Do we have to start with the pre-assessment?
- No, it is not mandatory. The pre-assessment speeds up scoping if you do not yet have a full picture. If you already know what is missing, we can start this module directly.