Connected evidence: reading compliance from your systems, not your screenshots

There are two ways to prove a control is operating. You can have someone open the system, take a screenshot, and file it, or you can read the control's state directly from the system that enforces it. They look similar in an evidence binder and they are not remotely the same proof. The screenshot is an assertion: a human says the control was on at a moment they chose, and you are trusting the human, the timing, and the absence of edits since. The query is an observation: the control's actual state, read from the source, current, and repeatable. This is rung three of the evidence maturity ladder, where evidence stops being a description of the system and becomes a reading of it.

Connected evidence is the practice of reading control state read-only from the systems an organisation already runs: identity providers, ticketing and change-management tools, cloud configuration, log and SIEM pipelines, device management, version control. It is framework-agnostic, and it is the difference between a compliance programme that costs a fortune to assemble at audit time and one whose proof is already current.

Asserted evidence versus observed evidence

The auditing profession has been explicit that the source of evidence determines its weight. The PCAOB's audit-evidence standard (AS 1105) states the principle plainly: "the reliability of evidence depends on the nature and source of the evidence," and "evidence obtained directly by the auditor is more reliable than evidence obtained indirectly." The same standard holds that information produced by the organisation is more reliable when the controls over that information, including IT general controls and automated application controls, are effective. The 2024 amendments, effective for fiscal years beginning on or after 15 December 2025, raise the auditor's responsibility to evaluate the reliability of electronic information used as evidence.

Map that onto compliance and the hierarchy is obvious. A screenshot is indirect, point-in-time, and only as trustworthy as the person who took it. A read-only reading from the enforcing system is direct, current, and reproducible. One is an assertion that a control operated; the other is an observation that it does.

The standards now expect ongoing, automated readings

This is not a preference, it is increasingly a requirement. NIST's foundational guidance on Information Security Continuous Monitoring (SP 800-137) defines the goal as "maintaining ongoing awareness of information security, vulnerabilities, and threats," and is explicit that automated tools are what make that "ongoing awareness" affordable and consistent rather than a periodic snapshot. The companion control in NIST SP 800-53, CA-7, operationalises it by requiring a continuous-monitoring strategy with automated, near-real-time visibility into control effectiveness. For US cloud providers, FedRAMP's continuous-monitoring regime turns this into a hard cadence: monthly vulnerability scans and monthly deliverables giving authorising officials ongoing insight into security posture, not an annual review. NIST's OSCAL initiative is building the machine-readable rails so that control and assessment data can be exchanged and traced automatically rather than copied by hand.

The sectoral frameworks are moving the same way. PCI DSS 4.0.1 made automated log review mandatory as of 31 March 2025, requiring a mechanism such as a SIEM rather than manual inspection. ISO/IEC 27001:2022 requires, in its monitoring clause, methods that produce comparable and reproducible results and retained documented evidence of them, which favours system-derived readings over one-off captures. And SOC 2's common criteria map cleanly onto system readings: CC6.1 is multi-factor enforcement you can read from the identity provider, and CC6.2 and CC6.3 are provisioning and periodic access reviews you can read from the identity-governance and HR systems rather than re-describe in a form.

What connected evidence actually reads

In practice, connected evidence answers control questions by querying the system of record. Is MFA enforced? Read it from the identity provider. Were access reviews completed this quarter? Read completion from the access-governance tool. Was this change approved and ticketed? Read it from the change-management system. Is encryption configured and are the right settings live? Read it from the cloud APIs. Are logs intact and monitored? Read it from the SIEM. Each reading is observed, timestamped, and traceable to its source.

The cost of not doing this is well documented. A 2025 survey of five hundred security and IT decision-makers found that seventy-one percent believed their organisation could fail a cyber audit, more than half spent over five hours a week on manual compliance tasks, ninety-two percent relied on three or more tools just to gather audit evidence, and on average only thirty-nine percent of the evidence process was automated. That is most of the work still being done by hand, producing exactly the rung-one artefacts auditors trust least. The market response has a name: Gartner tracks "Continuous Controls Monitoring" as a category, and the platforms in it advertise hundreds of integrations, several hundred connectors each, because connectors are the connected-evidence model made literal: pull the state from the source, continuously, and alert when it drifts.

The same expectation appears in the MENA frameworks. The UAE's ADHICS standard, effective from August 2024, leans on continuous security monitoring with SIEM and round-the-clock oversight, and Saudi Arabia's SAMA Cyber Security Framework expects control performance to be monitored against key performance indicators with automated, real-time monitoring. Different regulators, same instruction: read the state, do not wait for someone to write it down.

The architectural answer

Connected evidence is not a feature you can bolt onto a binder. A platform either reaches into your systems and reads control state, or it asks your team to keep describing it. Novantra's connected-evidence connectors read control state read-only from the systems you already run, so evidence is observed rather than asserted. Novantra's verified telemetry then source-links and freshness-scores each reading, and Novantra's hash-chained audit and operation ledger make the record tamper-evident, which carries the same evidence from rung three up to rungs four and five of the ladder. Because Novantra's Sovereign deployment runs inside your own infrastructure with customer-controlled keys, the connectors read your systems without your data leaving your boundary. The engineering substrate is covered in audit-grade evidence as a continuous output and the daily operating model in operating audit-ready every day; the deployment foundation in sovereign by architecture.

The shift is simple to state and hard to fake: stop uploading evidence and start reading it. The systems already know whether your controls are operating. Connected evidence just asks them.