Management Systems

The Management Systems module is where you record the programs your organization runs to manage a particular area of governance. An information security management system (ISMS), a privacy program, an AI governance program, a vendor risk program, a resilience program: each is one management system, with its own scope, owner, objectives, and operating cadence.

This module is deliberately not named after any one program type. The same shape supports a formal ISO-style management system, a board-mandated privacy program, an emerging AI governance program, or an internal compliance program your organization invented for itself.

When you would reach for this

You set up management systems when:

• A standard or regulator expects you to run a formal program (an ISMS for information security, a quality management system, a privacy program with named accountabilities).
• Your organization runs governance work as discrete programs and you want a single record per program where its scope, objectives, owner, and supporting evidence converge.
• You need to demonstrate to an auditor or board that a named program exists, who runs it, what its objectives are, and how it’s measured.
• A framework’s certification or accreditation depends on the demonstrable existence and operation of a program.

You don’t reach for this when capturing individual controls, risks, or evidence. Those records belong to the modules with their own names; a management system is the umbrella that organizes them.

What lives in a management system

Two record types:

1. Management system is the program itself. Has a name, a stable key you pick, a system kind describing what kind of program it is, an optional scope (which part of the organization it covers, via Scope), an owner (a responsibility assignment), and an optional snapshot capturing additional program-level posture (interested parties, communications plan, competence framework, etc.).
2. Management system objectives are the measurable goals the program has set itself. Each objective has a title, a kind (strategic, operational, compliance, risk-reduction, performance, etc.), a target snapshot (what success looks like) and a measurement snapshot (how it’s measured).

System kinds

When you create a management system, you mark it with a system kind describing what kind of program it represents. Common kinds:

Kind is free text. Pick the label that matches how your organization describes the program internally.

A worked example: a mid-size SaaS provider

A SaaS provider running customer workloads in cloud infrastructure operates four formal programs:

• An information security management system (ISMS).
• A privacy program covering customer and employee personal data.
• An AI governance program, recently stood up because the product team has started shipping AI features.
• A vendor risk program for the cloud providers and SaaS tools the company depends on.

The compliance director, Marcus, sets up Management Systems like this.

Step 1: register each program. From Governance → Management Systems, Marcus creates four top-level records: isms, privacy-program, ai-governance, vendor-risk. Each gets a name, a one-paragraph description, and a system kind.

Step 2: scope each one. Some programs cover the whole organization (the ISMS and the privacy program). Others cover specific parts: the AI governance program initially applies only to the product engineering organization, so Marcus links it to the product-engineering scope node from Scope. As the program expands to other parts of the company, he can update the scope.

Step 3: assign owners. Each program needs an accountable owner. The ISMS owner is the CISO; the privacy program owner is the DPO; the AI governance program owner is a newly-hired AI risk lead. Marcus assigns each program’s owner through a responsibility assignment so the audit trail clearly names who is accountable.

Step 4: capture program-level posture. For the ISMS, Marcus uses the program’s snapshot to record the interested parties (regulators, customers, employees, board), the communication plan (quarterly board reporting, annual all-hands update), and the resource commitment (FTE counts and budget). For the privacy program, he records the legal basis catalogue. For AI governance, he records the model lifecycle stages the program oversees.

Step 5: set objectives. Under each program he adds objectives. The ISMS has objectives like “Reduce mean time to detect security incidents” and “Achieve zero high-severity audit findings for two consecutive years.” Each objective has a target (the numeric or descriptive goal), a measurement plan (how it’s tracked), and a status field.

Six months later when the board asks “what governance programs do we run, who owns them, and how are they performing?”, Marcus opens Management Systems and walks through four pages. Each page has the program’s scope, owner, objectives, and links to the controls, risks, evidence claims, and findings that the program touches.

What you’ll see in the product

Management Systems lives under Governance → Management Systems in the workspace.

The Management Systems list shows every program you’ve registered, filterable by status and kind. The list is intentionally short; most organizations have between three and ten programs.

Inside a management system, you see its scope, owner, objectives, and snapshot. From here you can navigate to:

• The Controls the program oversees.
• The Risks the program tracks.
• The Evidence the program collects.
• The Assurance engagements that audit the program.
• The Submissions the program produces.

These cross-references aren’t hand-curated; they appear automatically as records in those modules name the management system in their own scope or coverage links.

Inside an objective, you see the target, the measurement plan, the current status, and the indicator measurements (if the objective is tied to a measurable Indicator).

Every change is captured in the workspace Audit Log.

Snapshots

The management system’s program snapshot and the objective’s target and measurement snapshots are flexible JSON-shaped fields. Use them to capture program-specific posture that doesn’t fit cleanly into other modules: the interested-party register, the communications cadence, the management review schedule, the resource commitment, the certification status.

For auditable programs (ISMS, privacy program, etc.), this is where you keep the program-level posture that the auditor will ask about.

Common workflows

Standing up a new program

1. Management Systems → New management system. Pick a kind that fits, a stable key, a name, and a short description.
2. Decide whether the program covers the whole organization or a specific scope. Link to the scope node if applicable.
3. Assign an accountable owner.
4. Capture program-level posture in the snapshot.
5. Add the program’s objectives.
6. As you create controls, risks, and evidence claims, link them back to this program.

Conducting a management review

1. Inside the program, review the linked controls, risks, evidence, and assurance work.
2. Review the objectives and their measurements.
3. Record management-review outcomes in the program snapshot (decisions, actions, opportunities for improvement).
4. The review is automatically captured in the audit log.

Retiring a program

1. Mark the management system as retired.
2. Existing links from controls, risks, and evidence to the program remain visible for historical context.
3. The program no longer appears in selection lists for new records.

Related

• Scope - where the program operates.
• Controls - what the program oversees.
• Risks - what the program tracks.
• Evidence - what the program collects.
• Assurance - what audits the program.
• Indicators - how the program is measured.