Earlier this year, we wrote about building an alternative to Confluence: why we built our own wiki for our ISMS. What we did not mention was the mess left behind after such a migration. Thirty of our procedures still contained instructions for the old Confluence environment. Instructions that nobody can follow anymore because that system no longer exists.

I found and cleaned them all up in a few hours without opening a single procedure myself. This post explains how.

The maintenance work

Everyone who maintains a management system knows the routine. Creating the same assessment pages each year. Checking that every report has been completed properly. Keeping references consistent across dozens of pages written by different people.

This work is part of the job and it does get done. But it is manual work: lots of clicking, lots of repetition and little thinking. Every hour spent on it is an hour not spent on what a management system is really for: thinking about your risks and improving your processes.

A CLI for your management system

Alongside its web interface, Normatik has a command-line interface (CLI). Everything you can do in the browser can also be done from the terminal: reading, creating, editing and publishing pages. Your content is not trapped behind a sequence of clicks; it is accessible to scripts too.

I am not a developer, and I am not going to write scripts to search thirty procedures. On your own, a CLI like that is not much use to you. Fortunately, you no longer need to do it alone.

A colleague who takes over the clicking

I do not use the CLI myself. An AI agent does that for me — Claude Code in my case. I describe a task in ordinary language, as I would to a colleague. The agent breaks it into steps, writes the scripts, executes them through the CLI and shows the result. It is not a chatbot typing commands for you; it is a colleague taking over the clicking.

For the procedures, my request was roughly: “We have moved from Confluence. I suspect our procedures still contain instructions referring to the old environment. Search all procedures and identify the Confluence legacy that remains.”

The agent read all the procedures through the CLI and returned four types of legacy:

  • dead instructions: steps referring to Confluence functionality that no longer exists
  • outdated descriptions: explanations of how the old environment worked technically
  • old links: references still pointing to the former wiki
  • broken references: links broken during migration

For each procedure, with the exact passages included.

Then came the real work, and that involved no machine. For each category, you must decide what to do. Dead instructions can go. A description of the old approach may still have value. A broken link can be repaired, but you need to know where it should lead. The agent proposed a cleanup for each procedure, I reviewed the proposals, and only then was anything changed and published.

Is that safe?

Giving an AI agent access to your entire management system rightly raises questions. The most important one: where does the content of your ISMS go?

The agent reads our pages, so that information passes through the systems of Anthropic, the company behind Claude. Before using it, we therefore assessed Anthropic as we assess every supplier: what happens to the data, where it is processed, how long it is retained and whether it is used for training. The outcome: our data is not used to train models, and processing is contractually defined. This is not special treatment; it is the same assessment every new tool receives here. The agent only started work once it met our requirements.

Could the agent break something? In theory, anything I could, because it works under my account. In practice, nothing enters the system unseen: changes are prepared as drafts first, I approve them, every change is logged and earlier versions can be restored. Anyone who remains concerned can give the agent an API key with limited permissions. Responsibility remains with me in any case — only the typing is delegated.

What else it delivers

We now use this pattern throughout our ISMS work. A few examples:

  • formatting errors: another migration legacy — lists displayed as plain text full of asterisks, bold formatting that was never closed and leftover empty markup. The agent scanned the entire system and found 49 pages, then fixed them through the CLI. From the first scan to the final repair: one afternoon.
  • access reviews: we periodically check who has access to which system. For each system, from Normatik itself to server administration in another tool, the agent lists users and roles and creates a review report in Normatik. We only need to assess whether everything is correct.
  • the newsletter: our internal ISMS newsletter keeps colleagues informed about developments in and around our ISMS. For each edition, the agent reviews the previous month's audit log and lists all changes. We choose topics from that overview and then write the newsletter ourselves.
  • AI compliance assessments: before adopting a new AI tool, we assess it against our requirements. This means going through documentation: privacy policies, terms of use and data processing agreements. The agent reads those documents, fills in our assessment table and creates a draft report in Normatik. We check the findings and make the judgement.

The common thread: the same maintenance takes a fraction of the time, and our attention goes to reviewing rather than executing. Because it runs through the CLI, every task is repeatable: next time, we simply ask the same question.

What comes next?

I expect this to become normal: a management system that you not only read and navigate, but can also access as a data source. Those ready for it can maintain their ISMS with a fraction of the effort. We certainly notice the difference every day.

Want to learn more about our Normatik application? Visit https://normatik.nl/.

Read more