A system of processes that runs, not a set of documents that describes.
A management system is the way an organisation establishes, implements, operates, monitors, reviews, maintains and continually improves a defined set of processes in order to meet a stated set of requirements. The requirements may come from a regulation, from a standard, or from the organisation's own policy. The system is the processes. It is not the folder that describes them.
That definition is older than the current wave of AI regulation. It is the form used by ISO management-system standards. It is the form of the quality management system required of a provider of a high-risk AI system under Article 17 of the EU AI Act. It is the form of the ICT risk-management framework a financial entity must operate under DORA. The words differ. The structure does not. Something is established. It is put into operation. It is watched. It is reviewed. It is kept current. It is improved when the review shows that it is not doing what it was established to do.
The point of this article is to fix that meaning before the series looks at any particular regulation. Most of the confusion in the current market comes from treating a policy, a register, a template and a certificate as if they were the system. They are not. Each of them can sit inside a system. None of them is one.
IBM made the point in the 1980s, that a system is people, process and technology, and the three have to move together. Technology on its own does not run. A process with no owner does not run. People with no process produce activity that cannot be sampled. The management system is the form that holds the three in one place.
The triad is older than the 1980s. Harold Leavitt set it out in 1965 as people, task, structure and technology. By the 1980s IBM, and the information-technology practice that followed it, had reduced it to people, process and technology, and was using it as the test of whether a change would hold. Change the technology and the process and the people have to change with it. Change the process and the people have to be able to run it. Leave any one behind and the system fails, however complete the other two look.
That is the history that matters here. It is why a management system is not a tool and not a document. It is why the duties now being written, Article 17, EN 18286, ISO/IEC 42001, DORA, NIS2 and the GDPR, ask for owners, processes and records, and not for a piece of software with a completeness score. The technology is the third element. It is not the system.
A management system has a scope. The scope says which activities, which systems, which products and which legal entities are inside it. A system with no scope is a statement of intent. A system whose scope is a list of every obligation the organisation has ever heard of is not operable. Scope is a decision about what the system will actually run, and it is the first thing an assessor or an authority will ask to see, because every later claim depends on it.
It has processes. A process has a trigger, an owner, inputs, activities and a work product. The trigger is the event that starts the work: a new system, a change of purpose, an incident, a supplier event, a date. The owner is the person accountable for the step. The inputs are what the step needs before it can start. The work product is the record the step leaves. A procedure that names none of these is a description. It is not a process, and it cannot be sampled.
It has criteria. The criteria say what "done" means for each process, and what "acceptable" means for the outcome the process is supposed to produce. Without criteria, a review has nothing to review against. A management review that asks whether people are busy is not a management review. A management review that asks whether the process met its criteria, and what will be done if it did not, is. Criteria are also what make proportionality possible. A low-risk internal tool and a system that changes a customer outcome can sit in the same system. The criteria, and the depth of the process, are what change.
It has records. The record is the evidence that the process ran. It is produced by the process, not assembled afterwards to describe it. A record that was written after the system was built, in order to fill a file, is a reconstruction. A record that was produced when the stage was passed, by the person who owned the stage, is evidence. The difference is visible to anyone who asks for the sequence: who did the work, who reviewed it, who approved it, and whether those were different people.
Establish means the organisation has decided what the system is. The scope is written. The processes are defined. The roles are assigned. The criteria are set. Establishing a system is a finite piece of work. It produces a defined system, not a permanent project. An organisation that is always "implementing" and never operating has not established anything. It has an open design.
Implement means the defined system is put to work on a real subject. For an AI system, the subject is a named system with an intended purpose. For a product under the Cyber Resilience Act, the subject is a product with digital elements. For a financial entity under DORA, the subject is the entity and its ICT arrangements. Implementation is not a pilot that never ends. It is the first time the process runs against something that is actually in scope, and the first time the record can be looked at.
Operate means the process continues to run as the subject changes. A model is updated. A supplier changes. A purpose drifts. An incident occurs. Operation is the daily work of the system: the stage is opened, the owner acts, the record is produced, the next stage is allowed to start. A system that was implemented once and then left is not being operated. It is a snapshot. Regulations that require post-market monitoring, vulnerability handling, or incident reporting are asking for operation, not for a snapshot taken at go-live.
Monitor and review mean the organisation looks at whether the system is doing what it was established to do. Monitoring is continuous. Review is periodic, and it has inputs and outputs. The inputs are the records the processes left, the incidents, the nonconformities, the changes in the requirement. The outputs are decisions: continue, correct, change the process, change the scope. A review that produces no decision has not reviewed anything. A review whose output is a slide, with no change to a process and no tracked action, is a meeting.
Maintain and improve close the loop. Maintain means the system is kept current when the requirement changes, when the organisation changes, and when the subject changes. Improve means a finding from review is turned into a change to the process, and that change is itself recorded. A corrective action that is agreed and then not tracked is a note. A corrective action that opens its own record, with an owner and a due date, is the system working. This is the part most often missing from a tool that marks a field complete and then has nowhere for the finding to go.
It is not a policy. A policy sets direction. The system is how that direction is carried out and how the organisation knows that it was. A policy with no process behind it is a statement. It can be approved by the governing body and still have no effect on a system in production, because nothing in the operating line is required to consult it, apply it, or record that it was applied.
It is not a register. A register lists things: systems, suppliers, processing activities, incidents. A register is an input to a process, or a work product of one. It is not the system. An inventory that is complete and a system that is operating are different facts. An organisation can have a perfect inventory and no process that runs when an item on it changes.
It is not a template library. A template can sit inside a process and shape the record. It cannot be the process. A completed template shows that someone filled fields. It does not show that a process ran, that an owner was accountable, or that a stage was not passed until the criteria were met. Templates are useful. They are not the system.
It is not a certificate. A certificate is a decision by someone else that, at a point in time, the system met a standard. The system is what was examined. An organisation can hold a certificate and no longer be operating the system. An organisation can be operating the system and not yet hold a certificate. The system is the prior fact. The certificate is a conclusion someone else drew about it.
The Institute uses "management system" in this sense across its work. Control Objectives for AI Systems (AICOB) is the process model that turns outcomes into assigned processes, controls, measures and assurance. The platforms are the environments in which those processes are run against a named subject, whether that subject is a high-risk AI system, a general-purpose model, a product with digital elements, a financial entity's ICT arrangements, or a controller's processing. The product name changes with the topic. The form does not.
The same platforms are available in two forms. They can be deployed as a stand-alone system. They can also run on Nextcloud, an open-source collaboration platform an organisation can host itself or have hosted. Nextcloud adds file storage, user and group management, and federation: selected records can be shared with another trusted Nextcloud instance, such as a group company, an authorised representative or a key supplier, without consolidating every system into one. The process model is the same in both forms. Nextcloud is the environment the record stays in.
That is a description of the approach, not a claim that using a platform produces conformity. Conformity is a decision by an assessor, a notified body or an authority, made on the evidence the system left. The system is what makes that evidence possible.
The duties now landing on organisations that develop, provide or use AI are written as systems. Article 17 of the EU AI Act requires a quality management system, documented in a systematic and orderly manner as policies, procedures and instructions, covering the life of the high-risk system. EN 18286:2026 is the European standard written for that system. ISO/IEC 42001 is a management-system standard for an AI management system. DORA requires a documented ICT risk-management framework under the management body's responsibility. NIS2 requires cybersecurity risk-management measures that the management body approves and oversees. The GDPR requires the controller to be able to demonstrate that processing meets the principles in Article 5.
Each of these asks for more than a completed list. Each asks for processes that run, owners who are accountable, and records that show the work. A management system is the form those duties are written in. The articles that follow take that form apart: what it does, how it differs from a list, what a governance framework is, what a process model is, and where controls fit. Only then does the series look at the individual systems.
