Continuous Monitoring, Control Assurance, and Compliance Drift

Quantum platforms change continuously. Backends drift, calibration routines evolve, compilers change routing behavior, cloud providers update runtime services, and governance rules accumulate exceptions. Continuous monitoring is the mechanism that keeps operating truth aligned with policy truth.

NIST SP 800-137 frames information security continuous monitoring as a strategy for visibility into assets, threats, vulnerabilities, and control effectiveness [R192]. Quantum operations need the same approach, extended to physical quality and scientific evidence.

Diagram loads as you read

Continuous Monitoring, Control Assurance, and Compliance Drift · Figure 1

View diagram source

flowchart LR
    Assets[Assets] --> Monitor[Continuous monitoring]
    Controls[Controls] --> Monitor
    Telemetry[Telemetry] --> Monitor
    Evidence[Evidence packages] --> Monitor
    Monitor --> Findings[Findings]
    Findings --> Risk[Risk register]
    Risk --> Action[Remediate, accept, transfer, or retire]

What must be monitored

Domain	Example facts
assets	QPUs, simulators, brokers, decoders, calibration stores, secrets, evidence stores
configurations	backend targets, compiler profiles, pulse libraries, runtime options, routing rules
controls	access rules, export controls, evidence requirements, approval gates, retention rules
physical state	calibration recency, drift, readout quality, environmental telemetry
scientific state	validation suites, benchmark history, reproducibility metrics
business state	cost burn, queue demand, vendor capacity, support incidents

Diagram loads as you read

What must be monitored · Figure 2

View diagram source

mindmap
  root((Continuous monitoring scope))
    Assets
      QPUs
      simulators
      brokers
      evidence stores
    Configurations
      compiler profiles
      runtime options
      routing policy
    Controls
      access
      retention
      approvals
    Physical state
      calibration
      drift
      environment
    Scientific state
      validation
      reproducibility

Compliance drift

Compliance drift occurs when actual operating behavior diverges from the authorized baseline. In a quantum platform, drift may be technical, scientific, or administrative.

Diagram loads as you read

Compliance drift · Figure 3

View diagram source

flowchart TB
    Baseline[Authorized baseline] --> Compare[Continuous comparison]
    Actual[Actual platform state] --> Compare
    Compare --> NoDrift[No drift]
    Compare --> Drift[Drift detected]
    Drift --> Classify{Classify}
    Classify --> Technical[Technical drift]
    Classify --> Scientific[Scientific drift]
    Classify --> Governance[Governance drift]
    Technical --> Remediate[Remediate]
    Scientific --> Revalidate[Revalidate]
    Governance --> Exception[Exception or policy update]

Examples include a compiler optimization changing without validation, a calibration validity window being exceeded but accepted by a scheduler, or an evidence store retaining records longer than the approved retention schedule.

Control assurance loop

Diagram loads as you read

Control assurance loop · Figure 4

View diagram source

sequenceDiagram
    participant Sensor as Telemetry sensor
    participant Policy as Policy baseline
    participant Monitor as Monitoring service
    participant Assessor as Control assessor
    participant Owner as Control owner
    Sensor->>Monitor: report state
    Policy->>Monitor: expected state
    Monitor->>Assessor: drift candidate
    Assessor->>Owner: finding with evidence
    Owner-->>Assessor: disposition
    Assessor-->>Monitor: updated status

The loop should preserve evidence. A compliance dashboard without source telemetry becomes another opinion layer.

Assessment cadence

NIST SP 800-137A discusses assessing continuous monitoring programs [R192]. For quantum operations, assessment should include both the monitoring machinery and the quality of the monitored facts.

Cadence	Review
daily	failed controls, policy exceptions, expired calibrations
weekly	SLO budget status, drift trends, high-risk changes
monthly	control effectiveness, evidence completeness, backlog aging
quarterly	risk posture, vendor scorecards, program objectives
release-bound	compiler, pulse, decoder, or runtime-profile changes

Diagram loads as you read

Assessment cadence · Figure 5

View diagram source

gantt
    title Continuous Assurance Cadence
    dateFormat  YYYY-MM-DD
    section Daily
    Control failures       :a1, 2026-01-01, 1d
    section Weekly
    Drift trend review     :a2, 2026-01-01, 7d
    section Monthly
    Evidence audit         :a3, 2026-01-01, 30d
    section Quarterly
    Risk review            :a4, 2026-01-01, 90d

Control evidence as data

Controls should emit machine-readable evidence.

Diagram loads as you read

Control evidence as data · Figure 6

View diagram source

flowchart LR
    Control[Control] --> Evidence[Evidence object]
    Evidence --> Schema[Schema validation]
    Schema --> Store[Evidence store]
    Store --> Dashboard[Dashboard]
    Store --> Audit[Audit package]

Minimum evidence fields:

control identifier
system component
expected state
observed state
observation time
source system
evaluator version
disposition
expiration or review date

Chapter close

Continuous monitoring is not a dashboard project. It is an operating contract: the platform will know what it is, what state it is in, what controls apply, where it has drifted, and who is responsible for restoring trust.