Monitoring

The Monitoring module is the continuous-checking layer of your governance program. Where Assessments ask “did we evaluate this subject in a point-in-time review?”, Monitoring asks “is this rule currently holding across the whole relevant population?” Monitors run on a cadence (every hour, every night, every week), check a defined population against a defined rule, and produce pass / fail / unknown results that you can act on.

A well-set-up monitor turns a control from “we believe it’s working because we wrote it down” into “we have ongoing evidence it’s working, and we’d know within hours if it stopped.”

When you would reach for this

You set up monitors when:

• A control’s continuous operating effectiveness matters and a quarterly assessment isn’t enough — you need to know now if it’s drifted.
• A regulator or framework expects continuous monitoring rather than point-in-time evaluation.
• A population (every user, every system, every supplier, every device) needs to be checked against a rule consistently.
• You want failures to automatically generate findings so remediation work flows in.
• You want monitor results to be the live signal behind compliance projections in Controls, Obligations, and Indicators.

You don’t reach for this for one-off point-in-time evaluations (that’s Assessments) or for the strategic risk decision behind a recurring concern (that’s Risks). Monitoring is the ongoing check.

What lives in monitoring

Three record types:

Monitor definition is the rule. It carries:

• A title and a stable key.
• The subject the monitor applies to (a control, an obligation, an asset class, a scope node).
• A population definition describing what’s being checked (which group of users, systems, suppliers, records, etc.).
• A rule definition describing the expected condition.
• A data source describing where the live data for the check comes from (an internal module, an external system, a manual collection).
• A frequency (scheduled, event-driven, manual, on-demand).
• A pass policy describing what “passing” looks like for this rule (e.g., 100% of the population, or 95% of critical-class items, or “at least one approved record exists this quarter”).
• A failure policy describing what to do when results fail (open a finding, raise a risk candidate, notify, escalate).
• An owner.

Monitor run is one execution of the monitor at a point in time. It carries the trigger (scheduled, event, manual), the actor, and the aggregate result.

Monitor result item is one record in the population’s result. For a 500-user population check, the run produces 500 result items (or a sample, depending on the rule). Each item carries its identifier, the result (pass / fail / unknown), and any explanatory metadata.

A worked example: a telecommunications operator runs continuous governance monitors

A telecommunications operator runs many subscriber-facing services across mobile, fixed broadband, and enterprise networking. Many regulatory and internal controls require continuous demonstration: every privileged access account has a current quarterly review, every customer-data-handling system has current encryption in line with policy, every contractor working on regulated systems has an in-date background check, every billing reconciliation runs daily.

The operations governance lead, Hiroko, sets up Monitoring like this.

Step 1: identify what to monitor. Hiroko works through the operator’s control library and picks controls where “continuous” is the right answer:

• privileged-access-quarterly-review — every privileged account should have a review record within the last 90 days.
• customer-data-encryption-at-rest — every customer-data storage system should report encryption posture as enabled, daily.
• contractor-background-check-validity — every active contractor on regulated systems should have an in-date check.
• billing-reconciliation-daily-completion — yesterday’s billing reconciliation should have completed without unreconciled records.

Step 2: define each monitor. For each, Hiroko creates a monitor definition:

• Subject: the corresponding control.
• Population definition: who or what is being checked (e.g., “every account with a privileged role in the IAM system”).
• Rule definition: the expected condition (e.g., “has a review record with timestamp within 90 days”).
• Frequency: daily for some, weekly for others, on-event for billing (after each daily run completes).
• Pass policy: typically 100% of the population for compliance-critical monitors; some allow a small failure tolerance with escalation.
• Failure policy: open a finding for any failure, with severity derived from the rule’s severity and the count of failing items.

Step 3: data sources. Each monitor needs to read live data. Some pull from internal modules (a monitor checking review records reads the evidence claims module). Some pull from external providers (an integration imports system encryption posture into the workspace). Some are manual (an operator records the latest result of a check that doesn’t have a programmatic source). The monitor definition captures the source.

Step 4: live operation. Once active, monitors run on their schedule:

• The daily privileged-access monitor runs every morning. Yesterday’s run produced 1,247 result items (one per privileged account). 1,243 passed, 4 failed (4 accounts had no review in the last 90 days). Four findings opened, each tied to the failing account.
• The daily encryption-at-rest monitor produced one failure (a newly-added system that wasn’t enrolled in the encryption-monitoring integration). One finding opened.
• The weekly contractor-background-check monitor identified two expiring within 30 days; the finding triggered the renewal workflow.

The control’s compliance projection updates from these monitor results: a control with 99.7% passing across its monitor’s population reads partially-compliant rather than compliant, and the four failing accounts are surfaced as the precise gap to fix.

Step 5: feedback into the program. When the regulator asks “show me you continuously monitor privileged access,” Hiroko opens the monitor definition, shows the rule, walks through 90 days of runs, and shows that failures became findings that were closed within SLA. The audit story is data, not narrative.

What you’ll see in the product

Monitoring lives under Governance → Monitoring in the workspace.

The Monitor definitions list shows every monitor configured, its subject, frequency, pass policy, last run result, and trend over recent runs.

Inside a monitor definition, you see:

• The full configuration (population, rule, source, frequency, pass and failure policies).
• The last several runs with their summary results.
• Trend charts of pass rate over time.
• Failing population items from the most recent run, with deep links to the failing subjects.
• Linked findings generated from failures.
• Linked evidence claims (the monitor itself can serve as evidence of continuous operation).
• Linked indicators (a monitor’s pass rate often feeds a KPI or KCI).
• Activity history.

The Monitor runs list is the historical record across all monitors: every run, when it fired, what its aggregate result was. Useful for compliance investigations.

Inside a run, you see every result item with its pass/fail/unknown state and metadata.

Every change to a monitor definition is captured in the workspace Audit Log. Run results are themselves part of the audit chain.

Pass policies

How “passing” is defined matters because it shapes the operational signal:

The pass policy lives in the monitor definition’s snapshot; the in-product UI walks you through choosing one.

Failure policies

What happens when results fail:

Common workflows

Defining a new monitor

1. Monitoring → New monitor definition. Subject, title, key, description.
2. Define the population (what’s being checked).
3. Define the rule (the expected condition).
4. Define the data source (where live data comes from).
5. Set frequency, pass policy, failure policy.
6. Assign an owner.
7. Test with an on-demand run; review the result items.
8. Activate; the monitor runs on its schedule.

Investigating a failing run

1. From the monitor’s detail page, open the failing run.
2. Filter result items by result: fail.
3. For each failing item, navigate to the underlying subject (account, system, contractor, etc.).
4. Verify whether it’s a real failure or a data issue.
5. Close failing-finding records as remediation completes.

Tuning a monitor

1. If a monitor is producing too many false positives, refine the rule or the population in the definition.
2. The previous monitor results remain visible historically; the new definition takes effect on next run.

Pausing a monitor

1. From the monitor, transition to paused with a reason (typically during a migration or known transient failure).
2. The monitor does not run while paused.
3. Resume when the transient condition is over; the audit log records the pause and resume.

Looking for the API?

See Monitoring API reference for the v1 REST endpoints to read monitor definitions and results from an external system.

Related

• Controls - monitors live behind a control’s compliance projection.
• Obligations - obligations may rely on monitor results to demonstrate compliance.
• Findings - failed monitors typically open findings.
• Risks - failed monitors can raise risk candidates.
• Indicators - monitor pass rates often feed KPIs and KCIs.
• Evidence - successful monitor runs can be evidence.