When does an ISMS make sense?
An information security management system is rarely an end in itself. Four triggers account for most projects, and they shape the cut more than any methodology does.
| Trigger | What follows for the ISMS |
|---|---|
| Customer and tender requirements | The scope has to cover the sites and services being supplied; a certificate becomes the goal |
| Regulatory duties (NIS2, DORA, GDPR among them) | The scope of the statute sets the frame, and reporting and evidence duties come on top |
| Supply chain requirements from large customers | The ability to evidence towards third parties is what counts, often without formal certification |
| An incident or a near miss | The absence of control has become visible; incident handling and recovery take priority |
Anyone starting without one of these triggers should answer the question of purpose first. An ISMS creates permanent effort (risk assessments, internal audits, management reviews, upkeep of evidence) that can only be justified where it pays into a concrete objective.
There is also a point past which informal security work no longer carries: when nobody can say completely which systems process personal or business-critical data, when access rights have grown historically, when measures exist but their effectiveness has never been checked, or when customer questionnaires regularly set off weeks of research. All four symptoms describe the same deficit: there is security, but there is no control.
Certification is a separate decision on top. An ISMS can be operated in full without being certified; a certificate, conversely, always presupposes an ISMS that is genuinely operated. Settle the goal early: a planned certification influences the documentation requirements and the cut of the scope.
The sequence at a glance
The familiar "seven steps to an ISMS" framing works as a mnemonic and fails as a project plan, because it does not say why the order is fixed. What matters is not the numbering but that each step needs the previous one's result as its input. Skip that input and you do not save time; you create work that comes due again later. The ISMS implementation checklist orders the first 90 days by the same logic, from mandate and roles through taking stock and the risk picture to routine operation.
| Step | Needs as input | Delivers | What happens if you skip it |
|---|---|---|---|
| 1. Clarify purpose and objective | A trigger (customer, statute, supply chain, incident) | A decision on certification, yes or no | The cut gets redrawn twice later |
| 2. Define the scope | Purpose, organisational and site structure | A documented boundary, interfaces included | Every later statement refers to nothing definite |
| 3. Capture assets and values | Scope | An inventory with owner, protection needs, dependencies | Risk assessment becomes an opinion poll |
| 4. Assess and treat risks | Inventory, documented criteria | Risk register, risk treatment plan | Measures cannot be justified in audit |
| 5. Select and implement measures | Risk treatment plan, Annex A as cross-check | Statement of Applicability, implemented measures | Annex A becomes a checklist, the ISMS interchangeable |
| 6. Document the governing documents | Measures decided on | Policy, topic-specific policies, procedures | Policies describe a state that does not exist |
| 7. Start operation and train | Approved governing documents | Records from day-to-day operation | The period over which effectiveness becomes visible is missing |
| 8. Check effectiveness | Records | Internal audit, management review, corrective action | The system ages unnoticed between two review dates |
Two steps can be pulled forward without breaking the logic. A gap analysis against the standard is worth doing as early as after step 2, because it makes the scope of steps 3 to 6 estimable, but it does not replace the risk assessment, only prioritises the preparation for it. And staff awareness can start early too; it is the one measure whose effect takes time to show, so it should not wait on the need for evidence.
How do you set the scope?
The scope is the first substantive step and the single most consequential decision. It fixes what every later statement refers to: which risks are collected, which measures apply, which evidence arises and, if you certify, what the certificate says.
The boundary is drawn along organisation (which legal entities, functions, roles), sites (which buildings, data centres, home-working arrangements), processes and services (which products or services), and information and systems (which data categories and applications).
The interfaces are what decide it. A scope that takes in a development department but leaves out the cloud platform it uses, the external IT provider and the group-wide identity management is not bounded, it is incomplete. For every interface facing outwards, establish who is accountable for it, which requirements apply, and how compliance with them is evidenced. What can be outsourced is the service, not the accountability.
For a first pass: start narrow, widen under control. A scope meant to cover an entire group of companies in one step regularly founders in the mid-market on the availability of the business functions. A cut that is too narrow, however, comes at a price: customers read the certificate closely, and a scope that does not contain the service being supplied is no help in a supplier assessment.
Record the boundary in writing, including the reasoning for any exclusions. That reasoning is the first thing an auditor asks about, and the first thing needed again when the scope is later extended.
How are assets and accountabilities captured?
Without an inventory, every risk assessment is speculation. Building the asset register is therefore the first substantial block of work, and the one projects most often underestimate.
What belongs in the inventory
The register holds more than servers and endpoints. The estate also includes information and data categories, applications and cloud services, networks and infrastructure, physical assets such as buildings and archives, service providers with access to systems or data, and knowledge tied to individual people.
No asset entry works without these:
- Owner. A named person, not a department. The owner decides on protection needs, access and the treatment of risks.
- Protection needs. A rating split by confidentiality, integrity and availability. A single overall grade conceals precisely the differences that matter.
- Dependencies. Which processes hang off it, and what it hangs off itself: operating system, hosting, service providers, interfaces.
- Currency. A date, and a procedure that carries changes through into the entries.
Use the sources you already have
The effort drops considerably where existing sources are used: the IT configuration database, the supplier and contract overview, the fixed asset register and, for personal data, the record of processing activities under ArticleĀ 30 GDPR. The last of these holds purposes, data categories, recipients and retention periods, and overlaps in large part with what the ISMS needs for information-related assets. Two registers maintained separately tend to drift apart inside a year.
A note on granularity: a register holding thousands of individual devices cannot be maintained. Form groups with the same protection needs and the same measures, and carry individual objects only where they genuinely differ.
How does the risk management process work?
The risk procedure is the core of the ISMS. It justifies why the organisation operates these particular measures. Without that justification, any list of measures remains a collection of opinions.
Criteria and the acceptance threshold
Before the first assessment, the criteria have to be set and documented: the scales for likelihood and impact, what feeds into impact (financial, legal, reputational, operational, rights of data subjects), how a risk value follows from these, and from which value onwards a risk has to be treated. That acceptance threshold is a management decision, not a technical one, and it belongs in writing.
The sequence in five steps
The sequence is the same across every common methodology:
- Identification. Risks are derived per asset or process from threats and vulnerabilities. Useful sources are the incident history, audit findings, supplier lists and the control catalogue as a cross-check.
- Analysis and evaluation. Rating against the defined scales, first without and then with existing measures taken into account. Distinguishing gross from net risk makes the contribution of each measure visible.
- Treatment. The options are reduce, avoid, transfer or accept. Every decision needs a named risk owner, a justification and a review date.
- Risk treatment plan. The measures decided on, with owners, dates and resources. The plan links assessment to implementation.
- Monitoring and repetition. Risks are re-assessed on a fixed cycle and additionally whenever something changes: new systems, new service providers, restructuring, and after incidents.
Where the process slips
Accepted risks are decisions of the management, not of the security officer, and have to be signed off by the person who carries the consequences. And the risk assessment is not a one-off exercise at project start: a register unchanged for a year although the system landscape has moved on is the most reliable indication of an ISMS that exists only on paper.
Selecting measures
Measures follow from the risk treatment, not the other way round. That order is the most important methodological difference between an ISMS and a security checklist, and it is also why auditors begin at the risk assessment.
Annex A as a cross-check
Annex A of ISO/IECĀ 27001 serves as the cross-check: once the measures have been selected, you test whether a necessary one was overlooked. In the 2022 edition, Annex A lists 93 reference controls across four themes.
| Theme | Count | Examples of subject matter |
|---|---|---|
| Organisational | 37 | policies, roles, supplier management, incident management, use of cloud services |
| People | 8 | screening, awareness, disciplinary process, remote working |
| Physical | 14 | physical entry control, secure areas, equipment protection, disposal |
| Technological | 34 | access management, cryptography, logging, vulnerabilities, secure development |
The short descriptions in Annex A consist only of a title and a terse sentence each. The full treatment, with purpose and implementation guidance, sits in ISO/IECĀ 27002. That standard is therefore the working document for implementation, while Annex A remains the normative frame of reference. ISO/IECĀ 27002 sets no management system requirements and is not certifiable.
Not every one of the 93 controls has to be implemented. Each one has to be considered, and the decision to apply or exclude it justified in a way that can be followed. That is exactly what the Statement of Applicability does, which the standard calls for in clause 6.1.3 d) as an output of the risk treatment. An auditor draws their sample from it.
The order of implementation
In setting priorities, pull forward the measures with broad effect (access management, logging, backup and recovery, supplier management, awareness) rather than following the order of the annex. Work the catalogue top to bottom and you will not be able to explain in the audit why the ISMS looks the way it does.
The second route: IT-Grundschutz
Annex A is not the only pool of measures. The BSI's IT-Grundschutz describes the same management-system logic in its own documents (BSI-Standard 200-1 for the management system itself, 200-2 for the methodology with its Basic, Core and Standard protection variants, and 200-3 for risk analysis), supplemented by the IT-Grundschutz-Kompendium with its modules. The methodological difference lies in the degree of freedom: IT-Grundschutz pre-empts part of the risk analysis by setting requirements for normal protection needs per module; a dedicated risk analysis under 200-3 is only required where protection needs are higher or no matching module exists. That lowers the burden of justification and raises the burden of documentation. Public administration and its service providers frequently require this route explicitly; it, too, leads to a certificate referencing ISO/IECĀ 27001.
Which evidence and documents does an ISMS require?
The standard calls for "documented information", not for a particular volume and not for a particular tool. The practical yardstick is this: everything needed to operate the system and to evidence its effectiveness must exist, be current, and be findable.
Governing documents and records
It helps to separate two kinds of material. Governing documents describe the target state: the policy, the topic-specific policies, procedures, the scope, the risk criteria, the Statement of Applicability. Records show that something was actually done: minutes, approvals, audit reports, training evidence, test results, tickets, access reviews.
The second kind is the harder one. Governing documents can be produced in a few weeks; records only arise in operation, over time. Where they are generated specially for an audit, the effort is merely deferred to the next one.
Two principles cut the maintenance effort permanently. First: evidence should arise where the work happens anyway, in the ticket system, in the approval workflow or in the logs, rather than in a parallel evidence store. Second: what counts is the linkage. A risk points to the measure, the measure to the SoA entry, the entry to the evidence, and the evidence to an owner. Break that chain and the evidence exists but cannot be attributed, and is therefore worthless for demonstrating effectiveness.
For each document, record the version, the approval, the owner and the review cycle. For records, the retention period comes on top, and it has to be reconciled with erasure duties under data protection law.
How do you run an ISMS over time?
An ISMS is laid out as a cycle. After the implementation, routine operation takes the place of the project, and the question is no longer "has it been built" but "is it being steered".
Recurring elements carry that operation:
- Measuring effectiveness. For each significant measure, define what its effect shows up in, and evaluate that regularly. Without this step, improvement remains an assertion.
- Internal audit. Run to a programme covering the whole scope across a cycle, carried out by people who are not themselves accountable for the area under review. An internal audit with not a single finding is itself a finding.
- Management review. Top management assesses the system against audit results, incidents, metrics, the status of measures and changes in context, and takes decisions on resources, objectives and improvements. Minutes without a decision meet the requirement formally, not substantively.
- Handling nonconformities. Every nonconformity needs a root cause analysis, correction of the individual case, action against the cause, and evidence of effectiveness. Fix only the symptom and you will see the same finding again in the next cycle.
On top of these come the event-driven triggers: new systems and service providers, restructuring, incidents, changed legal requirements. For each, it should be defined who informs the ISMS and which steps then start. Left undefined, the system ages unnoticed between two scheduled reviews.
Which roles does an ISMS need?
Overall accountability sits with top management; the standard says so expressly in its leadership clause. The task is delegated, the accountability is not. For regulated companies, the law assigns that same responsibility to the management body expressly. In Germany, Ā§Ā 38(1) BSIG obliges the management bodies of essential and important entities to implement the risk-management measures and oversee their implementation; Ā§Ā 38(2) attaches a liability toward the entity's own organisation under the rules of whatever company law applies to it; and Ā§Ā 38(3) requires the management body itself, not just its staff, to attend training on a regular basis.
| Role | Responsibility | Typical mis-staffing |
|---|---|---|
| Top management | policy, objectives, resources, risk acceptance, management review | involvement stops at a signature under the policy |
| Information security officer or CISO | steering the ISMS, methodology, reporting, coordination | a role with no time budget, no authority to direct, no access to management |
| Risk owner | assessment, decision on treatment, acceptance of residual risk | assigned collectively to a department instead of to a person |
| Asset owner | protection needs, access, currency of the entries | IT is recorded wholesale as the owner of every system |
| Measure owner | implementation and operation of individual measures | responsibility without resources |
| Internal auditors | independent examination of effectiveness | reviewing their own area |
Two conflicts have to be resolved. The security officer should not at the same time be accountable for the IT operation they assess; where a small organisation cannot avoid that, the separation has to be cushioned by reporting lines into management and by external review. And internal auditors must not audit their own area, which is the real obstacle in small organisations; reciprocal review between functions, or external auditors who do not also certify, resolves it. Why small organisations should cut roles to fit rather than copy a large-company structure is argued in compliance in small teams.
Data protection and information security remain separate roles with a clear interface. The data protection officer has a statutorily defined task and independence; the technical and organisational measures under ArticleĀ 32 GDPR nonetheless overlap to a large extent with the measures of the ISMS. Collecting assets, risks and evidence jointly saves duplicated work without blurring the roles.
How assets, risks, measures and evidence can be linked in a shared structure, so that the state of implementation stays demonstrable at any time, is shown on our information security page.
How Rizzqo enforces that order
The guide argues for a particular order: scope, assets, risks, then controls and documents. The trouble with a recommended order is that under deadline pressure everyone takes the shortcut and starts with the policies. In Rizzqo the order is not recommended but built into the structure, because each step needs the previous one as its input.
The scope is a set of objects rather than a passage of text: the primary assets, meaning information, processes and services, and the systems, applications, sites, providers and people-functions that carry them. Only with those links does a protection need exist at all, because it is inherited from the primary assets down to the supporting objects, including across several steps. And only once an object is classified do the requirements held for its category appear against it, from ISO/IECĀ 27002, ISO/IECĀ 27001 or a further catalogue.
From there the work runs where it belongs. Every requirement carries an assignee, is answered on the object with a reason and evidence, and is finalised under a name and a timestamp. What stays open is not ignored but consciously carried as a risk assessment, in likelihood and in impact in euros.