--- title: "Continuous Monitoring, Recorded as Evidence" description: "Continuous monitoring as evidence: every observation content hashed and chained, drift recorded as a finding with no authority attached, gaps declared." url: https://policycortex.com/solutions/automated-monitoring sealed: 2026-09-02 amended: 2026-09-02 register: solutions/automated-monitoring records: 5 digest: sha3:6af21ddaf15a718da2babf531acfda1761d7a595e81ab221b43a1ec5b568cd24 --- # Drift, recorded as a finding. NIST 800-53 CA-7 / SI-4 / NIST 800-171 3.14.6 / 3.14.7 Continuous monitoring is NIST 800-53 CA-7 and SI-4 written as evidence. PolicyCortex consumes the cloud event streams and configuration APIs you already pay for (CloudTrail, Azure Monitor, GCP Audit Logs), hashes every observation, chains it, and records a change made around the gates as drift with no authority attached: a finding, not a stale green. [Request verification](https://policycortex.com/contact) · [Book a call](https://policycortex.com/book) Read only. Fourteen days. No sales call required. ## What continuous monitoring must prove Every framework has a continuous monitoring requirement: NIST 800-53 CA-7 and SI-4, NIST 800-171 3.14.6 and 3.14.7, FedRAMP ConMon, the SOC 2 CC7 criteria. Each asks not whether you have a dashboard but whether you can show, for any interval, that the environment was observed, what it looked like, and what changed. Periodic scanners answer with the last scan. Event streams answer with a log line that something happened. Neither answers what was true between two dates, or says so when it was not looking. The audit failure mode is a green tile over a control that stopped being observed. Monitoring that cannot declare its own gaps is not evidence; it is a screenshot. - **mon.sources**: CloudTrail, Azure Monitor and the activity log, GCP Cloud Audit Logs, and the provider configuration APIs. Already enabled in most estates; PolicyCortex reads them. - **mon.cadence**: On schedule and on change. A change triggers a capture; a capture is a record whether or not anything changed. - **mon.identity**: Identity drift (Entra ID, Okta) is consumed from audit log streams. Application-level drift needs application instrumentation and is outside the default scope. - **mon.gaps**: A collector down or a scope unobserved produces a declared gap with interval and reason, never silently fewer rows. ## The evidence monitoring produces Monitoring written as evidence, not as a dashboard. Where each proof files: - **CA-7 · 3.14.6**: Proof of state: every observation content hashed with SHA3-256, timestamped, appended to the chain, retained seven years. A control that stopped being observed produces a declared gap, not a stale green. - **SI-4 · 3.14.7**: Proof of change: an alteration made around the gates surfaces at the next capture as drift with no authority attached, recorded as a finding with the delta hashed. - **AU-9 · AU-10**: The chain itself: monitoring records protected from modification and non-repudiable, because each digest commits to the record before it. - **Findings**: A finding carries severity, framework, environment, days open, and owner. The engine may propose a remediation and publish a confidence figure; it cannot execute. - **Machine actions**: Proof of agency: any remediation runs inside an envelope in the trust mode you set. GATED is the default; a named human approves and becomes part of the record. ![The PolicyCortex gap analysis: open compliance gaps stacked by control family and severity, each with framework, environment, days open, and owner](https://policycortex.com/images/pcx-gap-analysis-1600.webp) Exhibit SB-1 · open findings by control family and severity, each with framework, environment, days open, and owner. Declared, not hidden. Illustrative demo data; the interface is real. ## How monitoring evidence is verified For a continuous monitoring requirement the recomputation proves the interval was observed: the chain either recomputes across it, or it shows the declared gap where a collector was down, and never a green tile over a control that stopped being observed. Every record PolicyCortex writes for this obligation is content hashed with SHA3-256 and carries the digest of the record before it, so each line commits to the entire history above it. The log is append only: a correction is a new record, never an edit. Verification is a recomputation, not an assertion. Run the chain from the first record forward and it returns one of two answers: intact, or the sequence number of the first record that breaks. A second party can do that recomputation without our help. The records, the digests, and the chain rule are everything required: no PolicyCortex account, no API of ours in the loop. When a collector was down or a scope was unobserved, the chain carries a declared gap with the interval and the reason, never silently fewer rows. Absence is declared, not inferred. **Stated limit.** PolicyCortex is not an assessor and does not certify anything. It produces the records a compliance decision rests on; the assessor, the authorizing official, or the accountable official makes the determination. What is not connected is not observed, and the record says so. Control identifiers cite NIST SP 800-53 Rev 5, NIST SP 800-171 Rev 2, PCI DSS 4.0, SOC 2 TSC, ISO/IEC 27001:2022 and 45 CFR 164 as published. ## How you evaluate it against your event streams The fourteen days read the CloudTrail, Azure Monitor, and GCP Audit Logs you already pay for, so the first declared gap, if a collector drops, appears in your evidence during the evaluation rather than at the assessment. Connect read only for fourteen days, in SHADOW mode, inside your own tenant. Nothing executes. Policy evaluation, evidence collection, and action gating run where your data already is; there is no telemetry pipeline to PolicyCortex servers and no egress of evidence. At the end of the fourteen days you hold the records and can recompute the chain yourself. - **eval.mode**: SHADOW. Watch only; nothing executes. - **eval.duration**: Fourteen days. - **eval.location**: Your tenant. Azure, AWS, and GCP are observed clouds, including AWS GovCloud, Azure Government, and GCC High. - **eval.egress**: None. No telemetry pipeline to PolicyCortex servers; no evidence leaves the tenant. - **eval.after**: You keep the records. Licensing is annual and the tenant owns the evidence; a delivery engagement is optional. ## Questions assessors and buyers ask **Q: How is this different from Wiz, Prisma, or Defender scanning?** A: Those products scan on a cadence and show you the result. PolicyCortex consumes the event stream and the configuration APIs and writes every observation as a hash-chained record with declared gaps, so the question is not how fresh the dashboard is but what was true on the date the assessor names. The two are complementary; scanner findings can be consumed as records too. **Q: What about non-cloud drift?** A: Identity drift (Entra ID, Okta) is consumed from audit log streams. Application-level drift requires application instrumentation, which is outside the default scope but integrable. **Q: What is the false positive rate?** A: A finding is a recorded difference between expected and observed state, so the question becomes severity, not truth. The engine publishes a confidence figure with each remediation proposal; anything below the threshold you set goes to a review queue, not a pager. The thresholds are yours. **Q: What does stream ingestion cost?** A: CloudTrail, Azure Monitor, and GCP Audit Logs are already enabled in most environments. PolicyCortex reads them; there is no additional logging cost beyond what you already pay your cloud provider. **Q: What happens when a collector is down?** A: The chain carries a declared gap: the stream, the interval, the reason, and when it was declared. Evidence never silently has fewer rows. **Q: Where does the data live?** A: In your own tenant. There is no telemetry pipeline to PolicyCortex servers and no egress of evidence. Ask what was true on a date. Get a record, not a tile. [Request verification](https://policycortex.com/contact) · [Book a call](https://policycortex.com/book) ## Register colophon | Seq | Label | SHA3-256 | Prev | |---|---|---|---| | REC 0000 | OBLIGATION | fdd9e732f19b | fc935ec970e4 | | REC 0001 | EVIDENCE | 4c52cddf7cf3 | fdd9e732f19b | | REC 0002 | VERIFICATION | 96de8c9ace64 | 4c52cddf7cf3 | | REC 0003 | EVALUATION | 504093d4ab5d | 96de8c9ace64 | | REC 0004 | QUESTIONS | 6af21ddaf15a | 504093d4ab5d | Head sha3:6af21ddaf15a718da2babf531acfda1761d7a595e81ab221b43a1ec5b568cd24. Each digest is SHA3-256 over the previous digest, the register key, the record label, and the record copy; a second party can recompute it from this document.