Frameworks don't stand still. In 2022, ISO 27002 was restructured from 114 to 93 controls. BSI IT-Grundschutz gets a new edition every year. NIS-2 guidance is tightened every few months. If you track all this through the BSI newsletter, ISO mailings and tool update notes, you are bound to miss a change that matters.
What Framework Change Management Does
- Source polling: the platform checks official sources (BSI website, ISO update feeds, the EU Official Journal for NIS-2 annexes). It spots new versions on its own.
- Diff: a structured diff between the old and the new version lists changed, deleted and added requirements. You get more than a note that says "new version available".
- Impact analysis: for each changed requirement, you see which of your controls, policies and measures it affects.
- Reassessment workflow: the platform creates tasks for the owners, such as "Please re-align control X with new requirement Y".
- Audit log: it records which user acknowledged which change, and when. That answers the auditor's question: "Since when have you known about the change?"
Example: ISO 27002:2022 and a Hypothetical 2025 Update
Say ISO 27002 added a new control block called "Quantum resilience" in 2025. The platform would then:
- Find the new control and add it to the mapping matrix.
- Update cross-mappings to BSI building blocks (CON.X) and NIS-2 articles, as far as those standards have also changed.
- Send every tenant with ISO 27001 in active scope a notice: "Impact: 1 new control".
- Show the new control in the SoA view with the status "new, unreviewed" and assign an owner.
Why Manual Tracking Fails in Practice
Take a typical mid-sized IT team with a compliance lead at 0.5 FTE. Standard updates get missed for three reasons:
- The official newsletters are dull to read.
- At first, the change looks abstract ("requirement in chapter X.Y was rephrased").
- The compliance lead is busy with the current audit.
The result: the next audit finds the gap. You then fix it under stress instead of as a planned change.
The Auditor Argument: Proof of "Continual Improvement"
ISO 27001 and NIS-2 both ask for continual improvement of the ISMS. Look at log entries like these: "Standard update X found on 2026-03-15. Reassessment by Y done on 2026-04-02. Action plan approved by Z on 2026-04-05." In a certification audit, that is exactly the kind of proof that counts as "best evidence".
Conclusion
Framework change management is not a glamorous feature. But in the audit, it decides between a "working ISMS" and "findings". In 2026, tracking standard updates by hand no longer gives you an edge. People expect the platform to do this job, so the team can focus on the real changes.