A Management System and Traditional Compliance

Traditional compliance work is organised around artefacts. A regulation is read. Its obligations are copied into a spreadsheet or a tool. Each line is assigned a status. When the statuses are green, the work is treated as done. That method can track whether someone has looked at an obligation. It cannot show that a process ran.

A management system is organised around work. An obligation is mapped to a process. The process has a trigger, an owner, inputs and a work product. The work product is the record. The status of the line is a consequence of the record, not a substitute for it.

What a list is good for

A list is a good index. It stops an obligation being forgotten. It gives a new team a map of the duty. It is a reasonable way to start a gap analysis, provided the gap analysis is then used to build the process and not treated as the process itself.

A list is also a good scope artefact. A Statement of Applicability records which determined controls apply to which use, and which do not. It is related to ISO practice. It is not the system of internal control, and it is not an assessment of that system. Writing a SoA before the controls exist is how the map becomes the territory in the file and nowhere else.

What a list cannot show

A list cannot show that a control ran. The mark says the line was considered. It does not say who owned the step, what triggered it, what the inputs were, or what record it left. An assessor who asks what happened the last time the control was supposed to fire has nothing to look at except the mark, and the mark does not say.

A list cannot show sequence. Design, verification, validation, change and post-market monitoring are stages. A file that describes all of them, written after the system was built, fails a consistency test of the kind set out in Annex VI of the EU AI Act. That annex requires the provider to verify that the quality management system conforms to Article 17, that the technical documentation demonstrates the essential requirements, and that the design, development and post-market processes are consistent with that documentation. Consistency means the processes ran. A completed list is not consistency. The same test applies, in substance, wherever an assessor asks whether the file matches the way the system was actually built and operated.

A list cannot show a clock. Several instruments run from an awareness or classification time and ask for a sequence of reports: Article 14 of the Cyber Resilience Act, Article 23 of NIS2, Articles 33 and 34 of the GDPR, Article 55 of the EU AI Act, and the DORA incident rules. These apply where the organisation is in scope of them. A list can note that reporting is required. It does not record the awareness time, calculate the deadline, refuse a skipped stage, or keep the approved record. Those are process facts. The same is true of any instrument, anywhere, that starts a clock from the moment an organisation becomes aware of an incident.

The minimum-work trap

The pressure on compliance teams is real. The duties are multiplying, and the tools on offer are built to make a list look finished. A completeness score is a comforting number. It is also the wrong number. It measures how much of the list has been marked, not whether the organisation can produce the record the duty asks for.

The cost of that shortcut appears when something has to be reported, or when a supervisor or a customer asks for the file. The organisation then reconstructs the record from email, from personal drives and from memory. Reconstruction is slower than operation, and it is weaker. A record produced when the stage was passed, by the person who owned it, is evidence. A record assembled afterwards is a narrative.

Fines are not the argument for a management system. The argument is that the duties are written as systems, and a list cannot produce the record a system is asked to leave. An organisation that operates the system is in a position to answer. An organisation that has completed the list is in a position to explain why it cannot.

What changes when the work is a process

The same obligation, handled as a process, looks different. The regulatory register lists the obligation and links it to the evidence that meets it. The evidence is a work product of a stage, not a document uploaded to close a line. The stage has a gate. The gate checks that the record exists, that the right role has signed, and that the person who prepared it is not the person who approved it. Monitoring and incidents feed a corrective action, and the corrective action is itself a tracked record.

That is more work at the start. It is less work at the point of failure, because the record already exists. It is also reusable. One process-control activity can support more than one instrument when the mapping is explicit. The list approach duplicates the work and still does not join it up.

Where IT Governance's systems sit

IT Governance's platforms are built as management systems in this sense, not as checklist tools. Control Objectives for AI Systems (AICOB) is the process model. The platforms run that model against the subject the product is written for. They guide the work. They do not present a list of the regulation and ask the user to tick it.

The platforms are available stand-alone, and on Nextcloud. Nextcloud is an open-source collaboration platform. It adds file storage, user and group management, and federation, so a selected record can be shared with a group company, an authorised representative or a key supplier without consolidating every system into one. The process model does not change between the two forms.