Continuous compliance & controls monitoring agent

Compliance is still often proven once a year: screenshots, spreadsheets and sampled tickets are gathered in a pre-audit scramble. A continuous controls monitoring (CCM) agent instead queries the systems of record all the time, tests each control, stores timestamped evidence, and opens remediation tasks when something drifts. LLM agents add the part rule engines were poor at: reading policies and tickets, mapping one piece of evidence to several frameworks, and drafting the follow-up. Humans keep risk acceptance and sign-off.

Problem & value

• Today: control owners collect evidence manually for ISO/IEC 27001, SOC 2, NIS2, DORA, SOX/ICFR or internal control systems. Tests are sampled, evidence is stale by audit day, and one control is documented separately for every framework.
• AI value: (1) test the full population instead of a sample, (2) keep evidence fresh and timestamped, (3) map one control to many requirements, (4) triage failures and chase owners, (5) summarise regulatory changes against the control library.
• Regulatory pull in the EU: NIS2 requires risk-management measures and incident reporting for essential and important entities [2]; DORA requires ICT risk management, incident reporting and third-party oversight for financial entities, applying since 17 Jan 2025 [1]. Both reward evidence that is continuous and reproducible rather than annual.
• Evidence of benefit: vendors claim large effort reductions in audit preparation, but there are no independent benchmarks; measure your own baseline (hours of evidence collection per audit cycle) before trusting any figure.

Variants

• SaaS/security compliance (SOC 2, ISO 27001): cloud, identity, endpoint and code-repository checks.
• Financial services (DORA, BaFin/EBA outsourcing, MaRisk): ICT third-party register, incident reporting timelines, resilience-test evidence.
• Critical-entity operators (NIS2): supply-chain and security measures, management reporting.
• Finance / SOX-style ICFR: access-conflict (segregation of duties), journal-entry and approval controls in the ERP; links to AGENT-006.
• Internal audit & public sector: continuous auditing of procedures and rule adherence.
• AI-system compliance: logging and documentation evidence for the company's own AI systems (AGENT-025).

How it works

1. control library (OSCAL / GRC tool) + policies & regulations (RAG index)
2. scheduler / event triggers (config change, new user, new vendor)
3. evidence connectors (read-only APIs: cloud, IdP, MDM, ERP, ticketing, Git)
4. deterministic test (query/rule)
5. result + raw evidence snapshot (hash, timestamp)
6. LLM step: interpret unstructured evidence (tickets, policies, pull requests), map to requirements
7. exception triage (severity, owner, due date, similar past findings)
8. human review: control owner / compliance officer confirms, accepts risk or remediates
9. ticket + reminder + dashboard + audit export

• Deterministic first: where a control can be tested by a query (MFA enforced, disks encrypted, admin count, patch age), use code, not an LLM. The LLM interprets text and drafts, it does not decide pass/fail on its own for key controls.
• Agent tools: read-only API tools via MCP or function calling; write access limited to creating tickets and comments. Credentials are scoped, short-lived and logged.
• Human-in-the-loop: compliance officer approves new test logic, risk acceptances and anything shown to auditors or regulators; auditors sample-check the agent's results.

Data preparation

Data comes from many systems: cloud accounts, identity provider, MDM, ticketing, HR, ERP and CI/CD (via read-only APIs), plus the control catalogue (often an Excel sheet or GRC tool), policies in the DMS or on file shares, and earlier audit reports as PDFs. Typical gaps: no single control catalogue, controls without named owners, policies that contradict each other, evidence kept as screenshots in mail or on personal drives, and over-broad service accounts. Evidence collected from systems also contains personal data (user lists, access logs).

Preparation steps: (1) build one control catalogue with ID, owner, frequency and evidence type (PREP-019); (2) inventory systems and available APIs (PREP-005, PREP-001); (3) assign data owners (PREP-004); (4) create read-only service accounts with minimal rights; (5) convert policies to searchable text (PREP-013); (6) pseudonymise where full identities are not needed (PREP-022). Tools: spreadsheet or OSCAL for the catalogue, connectors of the chosen platform. Rough share of effort: 30-40 percent, mostly the catalogue and access set-up.

Implementation paths

Which path for whom

• SMB: A. Compliance-automation platforms with ready-made ISO 27001/SOC 2/NIS2 control libraries and connectors are mature, and the process is standard.
• Enterprise: B. Own control catalogues, SOX/ICFR needs and integration with in-house GRC, ERP and identity systems favour a build on cloud APIs.
• Developer: B. Read-only APIs plus an LLM API let you build control tests quickly; self-hosting rarely pays off.
• Public sector: C. Audit evidence, user and HR data and procurement rules favour a self-hosted stack on sovereign infrastructure.

Path A — Buy (recommended for most SMBs)

• Security-framework automation: Vanta, Drata, Sprinto, Secureframe, Scrut — integrations for cloud, IdP and HR, with AI agents for questionnaires and evidence review. Vendors state hundreds of automated tests; check independently [4][5].
• Enterprise GRC / CCM: Archer, OneTrust, ServiceNow IRM, SAP GRC, Diligent, MetricStream, SureCloud; Europe-based options include Secfix, DataGuard (DE) and Proliance (DE) — verify scope and hosting.
• Finance controls: SAP GRC / Process Control, BlackLine, Workiva, Fastpath (access analytics).
• Choose A when: the frameworks are standard, the stack is mainstream SaaS/cloud, and an auditor already accepts the tool's evidence format. Check EU data residency and the DPA.

Path B — Build on cloud APIs

• Models: a reasoning LLM (Claude, GPT, Gemini, Mistral — EU region or EU provider where required) for mapping, interpretation and drafting; small model for classification of tickets/evidence.
• Orchestration: an agent framework or n8n/Power Automate (AGENT-002); tools exposed via MCP servers for AWS, Azure, Google Cloud, Entra ID/Okta, GitHub and ticketing.
• Native cloud posture sources: AWS Config and Security Hub, Azure Policy and Defender for Cloud, Google Security Command Center produce the raw control signals.
• Store: control library in OSCAL JSON/YAML [3], evidence in write-once object storage with hashes, vector index for policies and regulatory texts.
• Choose B when: you need custom controls (e.g. internal process controls) or multi-framework mapping that off-the-shelf tools do not cover.

Path C — Self-host (open source)

• Control tooling: NIST OSCAL tooling and open-source policy-as-code (Open Policy Agent, Cloud Custodian, Steampipe with compliance mods, Prowler, Wazuh), plus open-source NIS2/ISMS tools.
• Models: open-weight reasoning/instruction models (e.g. Qwen3, Llama, Mistral families, gpt-oss) served with vLLM or Ollama; embeddings and reranker for the policy index.
• Hardware: HW3 for a 30–120B model giving good mapping quality; HW2 works if the LLM only drafts and the tests are deterministic.
• Ops effort: high — connectors, secrets handling and evidence retention are yours.

Path D — Custom training

Rarely needed. Fine-tune a small classifier for evidence-to-control mapping or for ticket triage only if you hold thousands of labelled historical findings. Anomaly models on access or journal data can add value but belong to ANOM/PRED use cases.

State of the art (2026)

• Agentic CCM is the vendor trend: agents query systems, run control tests, review evidence and draft findings; practitioner guidance says they suit evidence collection, continuous monitoring, questionnaires, regulatory-change tracking and attestation tracking, but not regulatory interpretation, risk acceptance or final sign-off [6].
• Machine-readable controls: NIST OSCAL is becoming the exchange format for control catalogues, assessment plans and results; research extends it to AI-lifecycle evidence [3][7].
• MCP-style connectors make read-only system access to agents uniform; the security risk of the connectors themselves (prompt injection through ticket text, over-privileged tokens) is the main design topic.
• Limits and failure modes: LLMs may rate weak evidence as sufficient; evidence of design is not evidence of operating effectiveness; agents see only connected systems, so scope gaps stay invisible; auditors may not accept AI-generated conclusions without re-performance; vendor "automated test" counts say nothing about test quality.

Shared resources & combinations

• Capabilities shared (agent-framework, workflow-automation, vector-db, guardrails): AGENT-002 workflow automation, AGENT-016 IT service management, AGENT-025 agent governance and observability.
• Natural combinations: KNOW-009 (regulation/standards Q&A as the policy RAG layer), DOC-016 (automated document-vs-rule checking), AGENT-006 (financial close controls), PRED-028 (risk-based audit selection), ANOM-006 (anomalous transactions as control signal).
• One self-hosted LLM server (HW3) can serve this and the other compliance/knowledge use cases.

Effort, cost & KPIs

• Path A: weeks to first monitored controls; subscription, typically priced by framework and company size; plus auditor fees unchanged.
• Path B: 3–6 months for a first framework with ~10 connectors; costs are connectors, engineering, tokens (small if tests are deterministic) and evidence storage.
• Path C: 6+ months and a platform team.
• KPIs: share of controls tested automatically, evidence freshness (median age), mean time to detect and remediate a control failure, audit-prep hours saved, audit findings per cycle, false-positive rate on alerts, share of agent conclusions overturned by humans.

People & change

Start with management (mandate, scope, which frameworks) and the compliance or internal-audit lead as process owner. IT and IT security must grant read-only access and review the agent itself, since it holds broad credentials (GUIDE-013). Control owners in finance, HR and operations need to understand that their systems are tested continuously and that findings become tickets for them. Involve the data protection officer early: evidence contains user, access and HR data, so a DPIA may be needed and an AVV with the platform vendor is required (GUIDE-005).

Works council: yes in practice. Continuous testing of access and activity logs is a technical system suited to monitor behaviour, so §87(1) no. 6 BetrVG applies (objective suitability suffices per the BAG); §90(1) no. 3 and, if needed, an expert under §80(3) also apply (GUIDE-004). A works agreement should exclude individual performance evaluation. Public bodies involve the Personalrat.

Pilot on one framework or ten controls. Typical concerns: "we are being surveilled" and "the agent decides on findings." Address them with transparent scope, human review of every failed control before escalation, and AI literacy measures for control owners (GUIDE-006).

Risks, regulation & compliance

• EU AI Act: typically minimal risk — a monitoring tool for systems and processes, not Annex III. Becomes sensitive if it monitors employees (e.g. scoring individual behaviour, evaluating work performance): then Annex III employment high-risk rules may apply, and emotion recognition at work is prohibited (Art. 5) [8]. AI literacy (Art. 4) applies to operators.
• GDPR: evidence includes user accounts, access logs, HR and email metadata; apply purpose limitation and data minimisation, store hashes or redacted snapshots, check works-council co-determination (BetrVG §87) and DPIA need when employee activity is analysed.
• Sector rules: DORA and NIS2 oblige entities to remain accountable for ICT risk management even with vendors [1][2]; auditors (ISAE 3000/3402, SOX) judge reliance on automated evidence.
• Security: the agent holds broad read access; use least privilege, no write to production systems, defence against prompt injection from ticket or document text, and immutable logs of every agent action.
• Mitigations: deterministic tests for key controls, human sign-off, periodic re-performance by internal audit, versioned test logic, model-change testing.

Getting started

1. Pick one framework and 15–25 high-value controls (access, MFA, backups, patching, vendor register).
2. Check which are testable by API; inventory read-only connectors and service accounts.
3. Trial 2–3 Path A tools on your real stack, or prototype three deterministic tests plus an LLM evidence summary.
4. Agree with your auditor which automated evidence they accept and in which format.
5. Run in shadow mode for a quarter; compare agent results with manual tests before switching over.

Sources

1. Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
2. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
3. NIST OSCAL — https://pages.nist.gov/OSCAL/
4. Vanta — compliance software for enterprise — https://www.vanta.com/resources/best-compliance-software-for-enterprise
5. Archer — future of continuous controls monitoring 2026 — https://www.archerirm.com/post/the-future-of-continuous-controls-monitoring-trends-and-insights-for-2026
6. SureCloud — agentic AI compliance tasks that work in 2026 — https://www.surecloud.com/blog-hub/agentic-ai-compliance-tasks
7. arXiv — Making AI Compliance Evidence Machine-Readable — https://arxiv.org/html/2604.13767v1
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj