CF01-018: Post-Deployment Monitoring Plan

AI Control Library / CF-01: Lifecycle Governance

Designation: Core | Control types represented: Operational

A dashboard does not establish oversight if no one knows which changes matter or who must act. The plan connects observations to decisions and keeps emerging failure from becoming routine operation.

Control requirement

Approve a post-deployment monitoring plan before consequential operation. Define what will be observed, accepted performance, alert criteria, review responsibilities, response actions and reassessment triggers across the actual deployment.

Why this matters

The control is effective when its required decisions and safeguards can be demonstrated in the actual workflow. An approved document or completed form alone is insufficient if the described actions are not performed.

How the control types work together

Operational controls provide the policies, decisions and recurring processes described here.

When it applies

Production and consequential pilot systems, including hosted models and agentic workflows with delegated actions.

Tailor depth and review frequency to potential impact, system authority and uncertainty. Document the reason for any exclusion; a supplemental designation does not make an otherwise applicable safeguard optional.

Ownership

The system owner is accountable; operational, domain and security teams implement assigned monitoring and response duties.

Implementation guidance

  1. Derive metrics and observations from intended use, evaluated limitations and risk scenarios; include quality, misuse and consequential actions as relevant.
  2. Define baselines, thresholds, sampling, review intervals and visibility gaps; justify choices based on potential impact.
  3. Assign alert recipients, coverage, investigation steps and authority to restrict, recalibrate or stop the service.
  4. Test the monitoring-to-response path before release and revisit the plan after incidents, drift, dependency changes or expanded use.

How to verify it

Use a representative sample of actual records or an authorized controlled exercise. A reviewer with suitable expertise should compare observed practice with the approved scope and acceptance criteria.

Test Expected result
Inject a representative adverse signal The intended reviewer receives it and initiates the defined response.
Inspect monitoring coverage against material risks Unobserved risks have explicit treatment.
Review a material workflow change Metrics, thresholds and response ownership are reassessed.

Record a finding when a required result is absent, evidence cannot substantiate the claim, or practice differs materially from the approved conditions. An exception may record accepted risk, but does not turn a failed safeguard into an effective one.

Evidence to retain

  • Approved monitoring plan
  • Metric definitions and baselines
  • Alert routing and response tests
  • Periodic reviews and resulting actions

Protect evidence according to its sensitivity and approved retention requirements. Retain enough detail to substantiate the assessment without unnecessarily duplicating confidential or personal information.

If the control fails

Escalate failed alerting, missing coverage or unowned monitoring to the system owner. Restrict consequential use where material failure would remain undetected or unattended.

Example in practice

Hypothetical example: A document assistant’s plan measures citation correctness and routes suspected disclosure to security. A quality decline triggers restricted use and evaluation rather than merely adding another point to a dashboard.

Related controls

Framework mappings

  • NIST AI RMF (MANAGE 4.1)
  • EU AI Act (Art. 72)
  • ISO 42001 (Cl. 9.1)

Review and maintenance

Review at the interval approved by the control owner and after a material change, relevant incident or failed assessment. Reassess the affected scope, update records and verify corrective actions before closing findings.

Back to Lifecycle Governance

Version 1.0

Scroll to Top