Tracking ISMS Measures: Status, Evidence, Roles

To track ISMS measures, give each one a status, owner, deadline and evidence, and treat it as done only once its effectiveness is verified. BSI-Standard 200-1 separates reviewing application from reviewing effectiveness, and for NIS2 entities Section 30(2) No. 6 BSIG requires procedures for assessing effectiveness. The KaitoSec Team combines these sources into a four-stage status model.

What does it mean to track ISMS measures?

Tracking ISMS measures means managing every agreed measure, from decision to effectiveness review, with status, owners, deadline and evidence. BSI-Standard 200-1 requires an implementation plan that assigns owners for implementation and for checking effectiveness. Measures arise from risk treatment, the Statement of Applicability, audit findings and legal obligations such as Section 30 BSIG.

A measure is therefore a work item with its own lifecycle, not a line in a risk or the Statement of Applicability. At minimum it has an origin and a closure that has to be evidenced. This guide calls each such unit a measure, whether a register calls it a control, requirement or task.

Measures typically come from five sources:

• Risk treatment under ISO/IEC 27001, Clause 6.1.3, produces measures in a risk treatment plan.
• The Statement of Applicability records which Annex A controls apply and whether they are implemented.
• Findings from internal and external audits lead to corrective actions under ISO/IEC 27001, Clause 10.2.
• Section 30(2) BSIG requires NIS2 entities to take risk-management measures in at least ten areas.
• The IT-Grundschutz Check delivers unmet requirements for implementation planning (BSI-Standard 200-2, Chapter 8.4.3).

The method behind the first source is covered in the article on how risks are assessed and treated under ISO 27005.

The IT-Grundschutz Kompendium states the core in ISMS.1.A10, a standard requirement: "The measures provided for in the security concept MUST be put into practice promptly. This MUST be planned and the implementation MUST be monitored." BSI-Standard 200-1 specifies in Chapter 8.2 that the implementation plan must include the "designation of those responsible for implementation and of those responsible for checking the implementation or the effectiveness of measures". ISO/IEC 27001 requires the risk treatment plan to be implemented in Clause 8.3. Tracking is what proves it.

Tracking serves two audiences. Internally, it steers who does what by when. Externally, it shows auditors, management and supervisors which state applied when.

How to map one control set across several standards is covered separately. This guide picks up afterwards: with what happens to a measure once it is mapped.

Which statuses does an ISMS measure go through?

Under this guide's status model, an ISMS measure goes through four statuses: planned, in progress, implemented and verified effective. Each transition needs its own evidence, because BSI-Standard 200-1 separates reviewing application from reviewing effectiveness. Two special statuses complete the model: deferred, with documented residual risk, and dropped, with a justification.

The status names are this guide's recommendation, not a normative requirement. What is documented is the separation of two reviews in BSI-Standard 200-1, Chapter 8.3: one checks whether security measures are applied as intended, the other whether they achieve the security objectives set.

The IT-Grundschutz Check under BSI-Standard 200-2, Chapter 8.4.3 records a "degree of implementation (unnecessary/yes/partially/no)" for each requirement. That is a target-versus-actual snapshot, not a measure's lifecycle. The two views complement each other: a requirement marked "partially" in the check becomes a measure with the status "planned".

Status model for ISMS measures. Compiled by the KaitoSec Team based on BSI-Standard 200-1/200-2, ISO/IEC 27001 and Section 30 BSIG; the status names are a recommendation, not a normative requirement.

Status	Meaning	Evidence that supports the status	Who sets the status
Planned	The measure has been agreed; owners, deadline and budget are set.	An entry in the implementation or risk treatment plan names the origin: risk, SoA, audit or obligation.	The information security officer or the risk owner.
In progress	Work has started and the deadline is running.	A work artefact shows progress, such as a change, a procurement or a draft.	The measure owner.
Implemented	The measure is in place and being applied.	Dated evidence of implementation exists, such as a configuration, an approved policy or a training record.	The measure owner reports it, the information security officer accepts it.
Verified effective	The measure demonstrably achieves its security objective.	A review result with date and reviewer exists: a test, a sample, an audit or a metric.	Someone who did not implement the measure themselves.
Deferred	Implementation has been postponed on purpose.	A management decision on the residual risk exists, with a compensating measure where applicable.	Management, on the information security officer's recommendation.
Dropped	The measure is not, or no longer, required.	A documented justification records why.	The information security officer, or the risk owner where a risk is involved.

Moving a status forward requires evidence. Moving back is normal: if evidence expires, an incident occurs or the system changes, the measure falls back to "implemented" or "in progress". Without a way to step back, the register shows a state that no longer holds.

That the implementer does not perform the "verified effective" review is this guide's recommendation, based on BSI-Standard 200-2, Chapter 10.1: reviews should not be carried out by those who developed the security requirements.

"Deferred" is not a siding. Under BSI-Standard 200-2, Chapter 9.2, the resulting residual risk should be "described transparently and submitted to management for a decision". For "dropped", the IT-Grundschutz Check requires a justification for unnecessary requirements: per Chapter 8.4.3, "the justification must be stated here".

Why is an implemented measure not yet effective?

Implemented means a measure is in place and being applied; effective means it demonstrably achieves its security objective. BSI-Standard 200-1 names two reviews and requires both; for NIS2 entities, Section 30(2) No. 6 BSIG requires procedures for assessing effectiveness. In an EU-wide ENISA survey, 63 percent of the SMEs surveyed had carried out no cybersecurity assessment at all in the preceding twelve months.

In Chapter 8.3, BSI-Standard 200-1 separates compliance from suitability. On compliance it says: "There must be a regular review of whether all security measures are applied and carried out as provided for in the security concept." On effectiveness: "It must be reviewed regularly whether the security measures are suitable for achieving the security objectives set." Methods it lists include analysing past incidents, interviewing staff and penetration testing.

Accordingly, BSI-Standard 200-2 recommends in Chapter 10.1 procedures "that review the implementation of the agreed measures on the one hand and their effectiveness and efficiency on the other". ISO/IEC 27001 requires in Clause 9.1 that you determine what is monitored and measured, by which methods, when and by whom, and when the results are evaluated. For NIS2 entities, assessing effectiveness is a legal requirement: Article 21(2)(f) NIS2 and Section 30(2) No. 6 BSIG require "policies and procedures to assess the effectiveness of cybersecurity risk-management measures".

Fictional example: A municipal utility with around 180 employees maintains the measure "offline backup of the control system servers". In the register it is marked "implemented", because the backup job is configured and the policy approved. Only a restore test shows whether the backup achieves its actual purpose: restarting the control system. Until then the measure is implemented, but not verified effective.

BSI-Standard 200-2 explicitly lists "exercises and tests … (e.g. backup restoration)" as a method in Chapter 10.1. The internal audit under ISO 27001 also produces findings on effectiveness. It is one source for reviewing individual measures, not a replacement for that review.

ENISA's NIS Investments 2025 report shows that regular assessments are not a given. Almost one in three organisations surveyed, and 63 percent of the SMEs surveyed, said they had not carried out any form of cybersecurity assessment in the previous twelve months. Respondents were 1,080 professionals from NIS sectors across the EU, 83 percent from large enterprises. For DACH mid-sized companies, the figure is therefore an indication, not a measurement.

Which evidence proves the implementation status, and when does it go stale?

Evidence proves the state of a measure at a specific point in time, not permanently. So every piece of evidence needs a date, a review period and the triggers for renewing it. In ISMS.1.A11, the IT-Grundschutz Kompendium provides for reviewing the security level at least annually and whenever there is cause (standard requirement, SHOULD).

This guide derives a working rule from this: an ISMS measure's status is only valid as long as its most recent valid evidence. If the effectiveness evidence expires, the measure falls back to "implemented". An intermediate status such as "effective, evidence missing" hides exactly the gap an audit asks about.

What makes evidence go stale?

• Evidence goes stale over time when the defined review interval has passed without new evidence.
• A relevant change to a system, process or organisation invalidates existing evidence.
• A security incident within the measure's scope calls its proven effectiveness into question.

BSI-Standard 200-1 requires in Chapter 8.3 that the security concept and documents be updated when operations change. BSI-Standard 200-2 puts it this way in Chapter 10.2: "The security concept and the associated documentation must be updated after every relevant change." Implementing Regulation (EU) 2024/2690 requires compliance to be monitored "at planned intervals and when significant incidents or significant changes to operations or risks occur" (Annex, point 2.2.3). It applies only to the entity types named in Article 21(5), first subparagraph, NIS2 and Section 30(3) BSIG, such as cloud providers, data centres and managed service providers.

Which evidence supports which status?

An approved document proves the content of a measure. A configuration or a log proves that it is actually applied. Only a test, a sample or a metric proves that it achieves its security objective.

For audit evidence to hold up over time, its earlier state should be preserved. ISMS.1.A13 provides: "The current version of existing documents SHOULD be accessible at short notice. In addition, all previous versions SHOULD be archived centrally." ISO/IEC 27001 essentially requires documented information to be controlled in Clause 7.5.3. Overwritten evidence can no longer show an auditor which state applied on the reference date.

This guide therefore recommends four details on all evidence: the date, the person who produced it, a valid-until date or next review date, and the link to the measure.

Who is responsible for a measure: measure owner, risk owner or information security officer?

Three roles share a measure: the measure owner implements it, the risk owner approves the treatment plan and residual risk, and the information security officer monitors progress and reports to management. Under BSI-Standard 200-2, completion of each measure is typically reported to the information security officer. In NIS2 entities, management's duty to oversee implementation remains under Section 38 BSIG.

Implementation needs a named person. BSI-Standard 200-2 requires in Chapter 9.4 that it be determined "who must implement which measures by when", with a sober reason: "Experience shows that without such a binding determination, implementation is considerably delayed or does not happen at all."

The risk owner decides whether a measure is sufficient, without having to implement it. ISO/IEC 27001 essentially requires in Clause 6.1.3 that risk owners approve the risk treatment plan and accept the remaining residual risks. Tracking starts where the risk register records the risk owner and the treatment plan.

The threads converge at the information security officer. Per Chapter 9.4, the information security officer "must" be kept informed of progress continuously and in turn report to management regularly.

For effectiveness, BSI-Standard 200-1 requires in Chapter 8.2 people responsible "for checking the implementation or the effectiveness". Under Chapter 10.3 of BSI-Standard 200-2, completeness and plausibility checks "should not be carried out by the authors of the concepts". This guide applies the idea to implementation: whoever implemented a measure should not review its effectiveness.

In small organisations, that can be someone from another department. A separate guide explains which roles an ISMS has to fill without a dedicated security team.

Role	Task for the measure	Source
Measure owner	Implements the measure and reports completion	BSI-Standard 200-2, Chapter 9.4
Risk owner	Approves the treatment plan, accepts the residual risk	ISO/IEC 27001, Clause 6.1.3
Information security officer	Monitors progress, informs management	BSI-Standard 200-2, Chapter 9.4
Reviewer	Checks effectiveness, as independently as possible	BSI-Standard 200-1, Chapter 8.2; ISO/IEC 27001, A.5.35 "Independent review of information security"
Management	Oversees implementation (NIS2 entities)	Section 38(1) BSIG; Article 20(1) NIS2

For NIS2 entities, Section 38(1) BSIG obliges management to "implement and oversee the implementation of" the risk-management measures under Section 30. Article 20(1) NIS2 requires that management bodies "approve the cybersecurity risk-management measures" and "oversee its implementation". The work can be delegated; oversight stays with management.

How do you set deadlines and escalate overdue measures?

This guide recommends a binding deadline for every measure and a defined escalation level if it slips. BSI-Standard 200-1 requires that the management member responsible for information security be informed when targets cannot be met. If budget is lacking, the residual risk should be submitted to management for a decision under BSI-Standard 200-2.

The implementation plan records the deadline. BSI-Standard 200-2, Chapter 9.4, lists "scheduling of implementation" among the details an implementation plan should include at minimum. Per Chapter 10.1.3, this plan makes "an evaluation possible of the extent to which this planning has been adhered to". The duty to check is set out in BSI-Standard 200-1, Chapter 8.2: "Compliance with the targets must be reviewed regularly."

For overdue measures, this guide recommends three escalation stages. Your organisation sets the intervals between them:

1. The measure owner explains the delay and receives a new, binding deadline.
2. The information security officer includes the still overdue measure in the next report to management.
3. Management decides on additional resources, a compensating measure or accepting the residual risk.

If a measure fails for lack of money, the action points for Chapter 9 of BSI-Standard 200-2 name the way out: "list compensating measures for measures that cannot be financed or cannot be delivered". Management decides on the remaining residual risk. Postponing a deadline without that decision is how measures typically vanish from the register unnoticed.

Deadlines also matter to supervisors. Under Article 21(4) NIS2, an entity that finds that it does not comply with the risk-management measures takes, "without undue delay, all necessary, appropriate and proportionate corrective measures". Operators of critical facilities are also subject to Section 39(1) BSIG: they provide evidence every three years, and where security deficiencies are found, the BSI may require the "submission of a suitable plan for remedying the deficiencies" and the "submission of suitable evidence that the deficiencies have been remedied".

Which metrics show the implementation status for audits and management reviews?

The implementation rate alone shows only how many measures are in place. This guide recommends three further metrics alongside it: the effectiveness rate, the share of overdue measures and the share of expired evidence. ISO/IEC 27001 expects the status of actions and corrective actions as management review input; BSI-Standard 200-1 cites reviewing earlier follow-up actions as an example.

The four recommended metrics are defined as follows:

• The implementation rate is the share of measures with the status "implemented" or "verified effective".
• The effectiveness rate is the share of measures with valid, passed evidence of effectiveness.
• The overdue rate is the share of open measures whose deadline has passed without a new decision.
• Evidence currency is the share of evidence whose valid-until date has not yet been reached.

A high implementation rate with a low effectiveness rate is normal in a young ISMS. Management needs exactly this gap to set priorities.

The measurement framework comes before the first evaluation. BSI-Standard 200-2 recommends in Chapter 10.1 defining at minimum which objectives are measured (WHAT), who is responsible (WHO) and when the results are evaluated (WHEN). Chapter 10.1.1 urges restraint: "metrics have limited informative value", and the effort involved should be in reasonable proportion to the result. ISO/IEC 27001 essentially requires in Clause 6.2 that owners, deadlines and the evaluation of results be set for security objectives.

For the management review, BSI-Standard 200-1 is clear in Chapter 8.3: "The management reports must contain all the information management needs to steer the security process." As examples, BSI-Standard 200-1 names an "overview of the current status of the security process" and a "review of follow-up actions from previous management reviews". ISMS.1.A12 adds as a standard requirement that the reports "SHOULD contain clearly prioritised proposals for measures".

ISO/IEC 27001, Clause 9.3, lists inputs including the status of actions from previous reviews, nonconformities and corrective actions, monitoring and audit results, and the status of risk treatment. What the management review under ISO 27001 has to decide is covered in the knowledge article.

In the PDCA cycle, the status of measures forms the Check stage; its results feed continual improvement under ISO/IEC 27001, Clause 10.1. In an audit, auditors test metrics against samples. A rate without traceable individual evidence proves nothing.

When is a spreadsheet no longer enough for tracking measures?

A spreadsheet is enough as long as each measure has one link, one current state and little evidence. It reaches its limits in three places: when status changes need traceable versioning, when evidence with expiry dates hangs off measures, and when one measure serves several risks and standards at once. BSI-Standard 200-2 recommends suitable tools for documentation in the security process.

For a small organisation with one framework and a manageable number of measures, a well-maintained spreadsheet can be sufficient. What matters is whether it still answers the audit's questions.

The first breaking point is history. A status has to be reconstructable for a reference date, and ISMS.1.A13 provides for archiving previous versions (standard requirement, SHOULD). An overwritten cell only shows the latest state.

The second breaking point is evidence ageing. Evidence with a valid-until date has to be attached to the measure and able to downgrade its status. With the document in a folder and the date in a spreadsheet column, the two are disconnected.

The third breaking point is multiple links. A measure often serves several risks, an Annex A control in the Statement of Applicability (SoA) and a Section 30 BSIG obligation. When its status falls back, all links must fall back simultaneously, otherwise the risk register, the SoA and the NIS2 evidence contradict each other. Setting up those links is the job of a control library in which one control covers several standards.

BSI-Standard 200-2 states in Chapter 8.4.3: "Suitable tools should therefore be used that support the creation and updating of all documents required in the security process."

For history and multiple links, compliance mapping in KaitoSec follows one principle: a measure is implemented once, maintained once and visible wherever it has a regulatory effect. The SoA, measure register, gap views and audit evidence all draw on the same current working state. Every change logs previous value, responsible person and date. The reports for audits and management reviews let you drill down into each framework by measure completion rate, owners and evidence status.

No software does the effectiveness review for you. Testing, sampling and deciding the status remain human work. You can see how measure, owner and evidence connect in KaitoSec using one of your own measures in a demo call.

Frequently asked questions about tracking ISMS measures

Is a ticketing system enough to track ISMS measures?

A ticketing system is enough for deadlines and responsibilities, but usually not for evidence. A ticket ends at "done"; an ISMS measure still needs an effectiveness review, dated evidence and a link to a risk, the Statement of Applicability or a legal obligation. BSI-Standard 200-1 requires effectiveness to be reviewed regularly, not just once at closure.

How often does a measure's effectiveness have to be reviewed?

ISO/IEC 27001 sets no fixed interval but requires you to define when monitoring and evaluation happen. In ISMS.1.A11, the IT-Grundschutz Kompendium provides for reviewing the security level at least annually and whenever there is cause (standard requirement, SHOULD). For the entity types covered by Implementing Regulation (EU) 2024/2690, such as cloud providers or MSPs, the risk treatment plan has to be reviewed at least annually (Annex, point 2.1.4).

What is the difference between a correction and a corrective action?

A correction eliminates the nonconformity found; a corrective action eliminates its cause so that the nonconformity does not recur. ISO/IEC 27001 also requires in Clause 10.2 that the effectiveness of corrective actions taken be reviewed and that evidence be retained. A corrective action from an audit therefore goes through the same statuses as any measure until its effectiveness is proven.

Can a measure count as effective if its evidence has expired?

No. Under this guide's status model, the measure falls back to "implemented" until new evidence of effectiveness exists. BSI-Standard 200-1 requires effectiveness to be reviewed regularly and the security concept and documents to be updated after changes. Older evidence proves only the state at that earlier review, not today's.

Does management have to oversee the implementation status itself?

For NIS2 entities, yes. Section 38(1) BSIG obliges management to implement the risk-management measures and to oversee their implementation; Article 20(1) NIS2 adds the approval of these measures. Operational work can be delegated to the information security officer; the oversight duty cannot. The information security officer reports to management regularly (BSI-Standard 200-2, Chapter 9.4).

What happens to measures that have no budget?

They are not quietly postponed; they are decided on. BSI-Standard 200-2 recommends describing the resulting residual risk transparently and submitting it to management for a decision. As an action point, BSI-Standard 200-2 also lists compensating measures for unfundable measures. The measure is then recorded in the measure register as deferred, with a documented management decision.

Sources

1. BSI-Standard 200-1: Managementsysteme für Informationssicherheit (ISMS) (Information Security Management Systems), Federal Office for Information Security (BSI), version 1.0, October 2017.
2. BSI-Standard 200-2: IT-Grundschutz-Methodik (IT-Grundschutz Methodology), Federal Office for Information Security (BSI), version 1.0, October 2017.
3. IT-Grundschutz-Kompendium, Baustein ISMS.1 Sicherheitsmanagement (module ISMS.1 Security Management), Federal Office for Information Security (BSI), Edition 2023.
4. ISO/IEC 27001:2022 Information security management systems, International Organization for Standardization (ISO), 2022.
5. Directive (EU) 2022/2555 (NIS2), European Parliament and Council of the European Union, 14 December 2022.
6. Commission Implementing Regulation (EU) 2024/2690, European Commission, 17 October 2024.
7. § 30 BSIG: Risikomanagementmaßnahmen besonders wichtiger Einrichtungen und wichtiger Einrichtungen (risk-management measures of particularly important and important entities), Federal Ministry of Justice, gesetze-im-internet.de, 2025 version.
8. § 38 BSIG: Umsetzungs-, Überwachungs- und Schulungspflicht für Geschäftsleitungen besonders wichtiger Einrichtungen und wichtiger Einrichtungen (management's duty to implement, oversee and train), Federal Ministry of Justice, gesetze-im-internet.de, 2025 version.
9. § 39 BSIG: Nachweispflichten für Betreiber kritischer Anlagen (evidence obligations for operators of critical facilities), Federal Ministry of Justice, gesetze-im-internet.de, 2025 version.
10. NIS Investments 2025, European Union Agency for Cybersecurity (ENISA), 8 December 2025.