Monitor: Continuous Evidence and What Auditors Actually Check at Surveillance

Certification is a snapshot. Surveillance audits test whether the snapshot was ever representative of an ongoing process.

Clause 9 requires monitoring, measurement, analysis, and evaluation of the AI management system’s performance and effectiveness, and Annex A includes control expectations for ongoing monitoring of deployed AI systems. Organizations that treat certification as the finish line consistently underinvest here, because monitoring produces no immediate deliverable the way a completed risk assessment or an approved control implementation does. It’s ongoing, unglamorous, and exactly where certifications go to die at their first or second surveillance audit.

What “monitoring” needs to mean, concretely, per control

A generic commitment to “monitor the AI management system” is not operational. Monitoring needs to be specified per control, or per control category, with a defined frequency, a defined method, and a defined owner. A human oversight control might be monitored via periodic sampling of decisions where a human reviewer overrode an automated output. A data governance control might be monitored via a quarterly review of training data sources against the original data governance assessment, flagging anything added since. A third-party control might be monitored via annual vendor reattestation plus event-driven review if a vendor discloses a material change.

The common thread: each monitoring activity has a trigger (time-based or event-based), a specific thing being checked, and a defined response if the check fails. “We’ll keep an eye on it” is not a monitoring plan; it’s an intention with no mechanism attached.

Continuous vs. periodic: matching cadence to control type

Not everything needs continuous, real-time monitoring, and treating everything as if it does is as much a design failure as under-monitoring. Controls tied to fast-changing conditions (model performance drift, automated decision patterns, incident and near-miss tracking) benefit genuinely from continuous or near-continuous monitoring, because the risk they address can change on a timescale of days or weeks. Controls tied to slower-changing conditions (governance policy currency, role and responsibility assignments, vendor contractual terms) are well served by periodic review on a quarterly or annual cadence, and continuous monitoring of them mostly produces noise.

The organizations that get this wrong tend to err in one particular direction: heavy continuous monitoring infrastructure for controls that don’t need it (often because it’s technically satisfying to build dashboards), and only periodic, manual review for the fast-moving risk areas that actually warrant continuous attention. Matching monitoring intensity to how fast the underlying risk actually moves is the design principle that should drive this stage.

Evidence vs. documentation: the distinction that decides surveillance audits

Documentation describes what should happen. Evidence demonstrates what did happen. A policy document stating that human reviewers must approve high-risk automated decisions is documentation. A log showing which specific decisions were reviewed, by whom, with what outcome, over the audit period, is evidence. Auditors conducting surveillance audits are specifically trained to probe for the gap between the two — asking not “what’s your policy” but “show me the last five instances of this control operating.”

This is where continuous evidence architecture creates a structural advantage. An organization that can query “show me every high-risk approval decision from the last quarter, with the risk assessment and control status each one relied on” and get an immediate, complete answer is demonstrating something an organization scrambling to reconstruct the same picture from emails and shared drives cannot demonstrate, regardless of how good either organization’s underlying practices actually are.

What auditors actually check at a surveillance audit

Beyond sampling specific controls, surveillance auditors are looking for signs of drift between the certified state and the current state: new AI systems that entered the organization since the last audit and whether they went through the Register/Assess/Mitigate/Approve pipeline properly, whether previous audit findings and nonconformities were genuinely remediated (not just closed on paper), and whether the monitoring function itself is producing anything — or whether it exists as a clause in a policy document with no operational activity behind it. A monitoring program with no findings, ever, over multiple audit cycles is itself a finding waiting to happen: it suggests the monitoring isn’t actually looking hard enough to find anything.

Closing the loop back to Register

Effective monitoring should periodically surface information that feeds back into the Register stage: a new AI capability someone deployed without going through intake, a vendor tool that quietly added a generative feature, a system whose actual use has drifted from its originally registered purpose. When monitoring closes this loop the whole five-stage cycle actually functions as a cycle, rather than five sequential phases that happen once and then stop.

That closure is really the thesis of this entire series: ISO 42001, implemented well, isn’t a project with a start and an end date marked by a certificate. It’s an operating rhythm — register, assess, mitigate, approve, monitor, and back to register again as the organization’s AI portfolio changes. Organizations that build it that way don’t just pass surveillance audits more comfortably. They know, at any given moment, what their AI systems are doing and whether the controls around them are.