We see it differently: we are not rebuilding Confluence, but creating a product perfectly suited to management systems such as an ISMS. Why? Here is the story...
A little history
We have been loyal Confluence users for a long time. Intensive use of Atlassian products at 42 once gave rise to Prepend, our sister organisation specialising in Jira and Confluence. When we started with ISO 27001, using Confluence was the obvious choice.
It soon became clear that Confluence had limitations for a highly interconnected ISMS with extensive reporting and an integrated PDCA cycle. We worked around those limitations by pushing Confluence to its limits, and beyond them with our own custom software. It worked — and yet, not quite. The tension was clearly noticeable.
Praise and rejection
We quickly realised that our ISMS was well designed. Auditors praised how tightly the system worked, and many prospects were deeply impressed by what we had achieved with the limited resources available to us.
Time and again, further collaboration fell through for essentially the same reasons:
- using Confluence was not always convenient
- the high-maintenance task of labelling pages was undesirable
- our custom tooling was undesirable
The vision — a wiki for ISMSs
Confluence is essentially a system offering so much freedom that it gets in the way of the desirable discipline of an ISMS. Take page properties, for example — a wonderful concept. They let you add metadata to a page and use it on other pages. Some of the power of a database, available in a wiki.
But Confluence implements this so loosely that the data cannot be used as navigable information. As a result, complex relationships are not easy to map. If, for example, you want to know which policies, procedures and risks belong to an Annex A control, you have to jump through quite a few hoops.
Our idea was to make page properties a first-class citizen of the wiki. Every page has a page type, and that type enforces the properties. This makes properties navigable and lets you model complex relationships. A bonus: dozens of manually maintained labels are no longer needed to model the connections between pages.
AI agentic development
The dream came closer in December last year, when Opus 4.5 (Claude Code) and GPT 5.3 (Codex) reached a level that made developing software with them more than worthwhile.
We first spent time developing skills from our existing codebases, giving the coding agents a clear understanding of our approach, principles, development philosophy and use of components. We applied that knowledge to a greenfield project codenamed ISMS Wiki. We started on 16 January and quickly developed the concept into something beyond a working prototype.
Drawing on years of experience, we gradually built in constraints that gave the coding agent resilience. When you code with coding agents, you assume things will go wrong during development and put guardrails in place so the agent can recover from its own mistakes. This differs from the traditional programming model, where you actively try to prevent mistakes during development. You gradually tighten a shrink-wrap around the coding agent's freedom of movement, so it operates only within the space you intend.
The product has now reached a size and quality that makes it ready for us to start migrating our own ISMS, approximately 3,000 pages, to the new system.
What comes next?
The platform supports the final product: ready-made packs for standards such as the NIS2 Directive, ISO 27001, DORA and NEN 7510. Compliance is obligatory, but it should not hurt any more than necessary. Get started easily and tick the boxes to meet your legal obligations.
The next step is to set up an NIS2 demo environment so we can show the outside world what a great product this is. Meanwhile, we are working hard on the website and developing useful tools to help businesses without specialists complete the necessary steps easily. More on that soon.