How We Built and Maintain Our ISO 27001 ISMS Documentation

Why ISO-27001

Security protects the assets at the heart of a business. Cyberattacks are increasing, including attacks assisted by AI. Companies are responding not only by protecting their own systems, but also by checking that their providers are secure. This helps reduce supply-chain risk.

Before we started certification, we already had many security controls in place. We wanted a certified system that would keep us focused on security and on improving those controls. That is why we chose ISO 27001.

We worked with a consultant to structure the policies before the official certification audit. You can also start with a policy kit: general policy stubs that you adapt to reflect your controls and organizational structure. The resulting policies feed into a Statement of Applicability: the document that records which ISO 27001 cPleasontrols apply to your organization, and why. You can share it with customers.

For each policy, we collected as much information as we could from our colleagues and used AI to merge it into the policy stubs. Then we reviewed the result to make sure it was accurate and that nothing important had been lost.

The internal basic wiki setup

Before certification, all our procedures already lived on our internal wiki. Because we develop Oxygen XML Editor, we were already familiar with structured technical documentation. We chose DITA, an XML-based standard that stores content as small, reusable topics, because we already had the tools to publish it and run reviews.

Our existing DITA wiki was stored in a shared Git repository, which gave us access control and a complete change history. We added a new ISMS chapter to its DITA map—the table of contents that organizes the topics—and created a topic for each piece of relevant information.

Certification needs

The Git repository provided the change history and access control.

We also needed a way to define and validate the information that describes each document, such as its owner, status, and review period. For editing, change auditing, and collaborative review, we used Content Fusion. To run SOPs and send event notifications, we built a custom application.

Defining and validating metadata

In DITA, this descriptive information is called metadata. DITA already provides useful built-in metadata, such as the author, creation date, and modification date, alongside the document text.

What helped us most was that we could extend this metadata. We added our own name/value fields in the topic header—the structured information stored with each document. The following are the fields we used, including the scheduling fields that apply to SOPs:

Each procedure also has a RACI table. It makes clear who does the work, who is accountable, who is consulted, and who must be informed:

Each policy has a simpler, two-row responsibility table:

We then needed to keep this metadata reliable, so we added validation. We used Schematron, a set of rules for checking XML content. It can check complex relationships, including relationships across documents.

Setting up policies and SOP templates

Based on this metadata, we created reusable SOP and policy templates. An SOP is a standard operating procedure: a repeatable set of steps for carrying out a process. Our SOPs are DITA task topics with a RACI table, prerequisites, steps, and a result. The policies are standard DITA topics with a minimum structure: scope, rationale, sections, and the simpler two-role responsibility table.

Writing the policies

Once the templates contained sample metadata, we used AI to help write the full set of policies. The approach was simple: our CTO took each control already in place, found the matching policy stub, and described the current implementation to AI Positron. It produced a first policy draft that we could review.

For the stubs not covered by existing controls, we assessed the risks and introduced new controls and policies.

All controls were listed in the Statement of Applicability, with links to the policies.

Collaborative review

Each document needs a review before approval. That is how we keep the information accurate.

We run Content Fusion Enterprise Server locally, so we used it for this. Content Fusion is a lightweight, Git-based DITA content management system (CMS). It made it easy to connect our existing wiki repository to a project and share it with the whole organization. Role-based access let us designate a few colleagues as authors, able to edit and create review tasks, while others could collaborate only in review tasks.

One useful Content Fusion feature is that several collaborators can work on the same document at once. They can edit with change tracking and add comments concurrently. Nobody has to wait for someone else to finish.

When a review is complete, the author can incorporate the suggested changes and create a new approved version. AI can also help smooth out the wording or bring together information from the comments.

SOPs are living documents that trigger events

In our company, we use a ticketing system. We needed execution tracking and an audit trail for the procedures that support our ISMS policies, so we used that system to manage them. The SOPs are authored once in the Content Fusion wiki project, then sent to the ticketing system as work items that people can carry out and close.

We built a Python web application that lets us push an SOP to the ticketing system. It shows each person a catalog of procedures and policies that match their role, with search and workflow-specific actions. For example, each SOP has a Push button. The application also has a calendar of documents due for review and a history view, so we can compare versions of the same document.

[screenshot from the dashboard]

Another challenge was staying consistent over time. For example, changing passwords on some systems or replacing UPS batteries needs more than instructions. It also needs a calendar event, or it is easy to forget. We decided it was simpler to keep the calendar in the application. Everyone named in an SOP's RACI table receives an email when it is time to run that SOP or review a document. We can now update the metadata and let the system respond, without synchronizing separate calendars.

Publishing

We use Oxygen Publishing Engine, a command-line tool running on our continuous-integration server, to generate and republish the HTML documentation to our internal portal whenever content changes. This publishing infrastructure is also available in Content Fusion. You can also generate an LLMS.txt file set: a structured set of instructions that an AI agent can use as a reference when it carries out an action.

To collect feedback outside the review workflow after publishing, we added Oxygen Feedback commenting to each page.

You can also add an edit link to each page so readers can propose a source change. The link opens the matching document in Content Fusion, where they can make the change in a personal workspace and create a review task. The document owner can then review and merge it into the main branch.

Conclusion

This is how we built an in-house ISMS using technical documentation tools. It has worked well for our ISO 27001 policies and for other company documents that benefit from the same approach.

Starting from version 29 of Oxygen, there will be a new project template available so you can use it to create new governance projects based on the ideas presented in this blog post.

Thank you for reading, and happy documenting! Please comment below if you would like more information.