GRC automation got it backwards: collect evidence, not data

The first generation of GRC automation made a promise: connect your systems, and compliance becomes manageable. Pipe your data in, let the platform aggregate it, and the scramble before an audit gets smaller. It was a reasonable promise for its moment. A decade later, the teams who bought it are still assembling evidence by hand when the auditor asks for it, still exporting spreadsheets at eleven at night, and still explaining to the board why the compliance programme that cost six figures is not producing the proof that the enterprise sales cycle demands.

The problem was not execution. The architecture was wrong from the start. The first generation of compliance automation asked the wrong question. It asked: how do we give compliance teams better access to their data? The right question is: how do we produce proof that controls are met, independently, at the source, continuously? Those are not the same question, and the answer to the first one does not get you to the second.

The way out is not a better GRC tool. It is a different posture altogether: observe controls at their source, record that they were met, hold the record independently, and deliver proof rather than data — across the whole business, not just the security lane. What follows is why that shift is necessary and what it looks like in practice.

01 / How we got here

Compliance started with checklists. An auditor asked whether a control was in place. Someone checked a box and signed their name. The implicit proof was the assertion itself, backed by the auditor's ability to sample-test it in the time available.

Spreadsheets expanded the scope without changing the structure. More controls, more columns, more people filling in cells. Screenshots were added as documentation — a picture of the Salesforce permission set, a PDF export of the Okta policy. Evidence was something you gathered when asked. The gathering was manual, the coverage was partial, and the result was point-in-time.

The GRC suites that arrived in the 2010s industrialised the spreadsheet. They gave compliance teams a place to store the controls, track the evidence requests, assign owners, and manage the audit cycle. The underlying model remained the same: humans collecting evidence, humans uploading it, humans attesting to it. The platform organised the work. It did not change the work.

Then came "compliance automation" — a wave of SaaS tools that promised to replace the manual evidence collection with integrations. Connect to AWS and pull your CloudTrail logs. Connect to Okta and pull your MFA status. Connect to your MDM and pull device compliance. The pitch was persuasive, and the tools did reduce the manual collection burden for the controls they covered. But they created two structural problems that the pitch did not address, and those problems are the reason the scramble persists.

02 / The data-possession problem

Every integration that copies data into a compliance platform creates a new risk surface. That statement is not a critique of any specific vendor. It is arithmetic.

When you pipe your AWS CloudTrail data into a compliance tool, you now have two places where that data lives: AWS, and the compliance platform. When you pull your Okta user records, your Salesforce account data, or your Microsoft 365 audit logs into a third-party platform, the same logic applies. Each copy is a new target, a new vendor-due-diligence obligation, a new data processing agreement, and a new entry in the incident response plan. The tool you purchased to help demonstrate that you protect sensitive data has become another place your sensitive data lives.

For mid-market companies operating under SOC 2, ISO 27001, HIPAA, or GDPR, this matters structurally. Your auditors will ask about your compliance tool as a sub-processor. Your customers' security teams will ask where their data flows. Your breach notification obligations apply if the compliance platform is compromised. The tool that was supposed to simplify your compliance posture has added a vendor, a risk, and an obligation.

There is a direct alternative. Observe the control at its source. In Salesforce, confirm that the permission set meets the control requirement. In Okta, confirm that MFA is enforced for the relevant user population. In AWS, confirm that the logging configuration is active. Record that each control was met — the timestamp, the finding, a hash of the evidence — and hold that record independently. The sensitive data never moves. The proof does.

03 / The self-grading problem

Evidence assembled and curated by the team being audited has a fundamental credibility problem. It is not that compliance teams are dishonest. It is that independence is what makes proof proof. An auditor's job is to verify controls, not to take the auditee's word for them. When the evidence was gathered by the same team that operates the controls, using processes the team itself designed, the evidence is as strong as the team's own diligence. That is not strong enough for the purposes that matter most.

This is the issue that stalls enterprise sales deals. A prospective customer with a serious security review process does not want to see your SOC 2 report assembled from screenshots your IT team took. They want independent proof. When a compliance programme produces evidence that the compliance team gathered, filtered, and presented, the honest answer to "can you prove it?" is "we asserted it, and here is our documentation of the assertion."

Independence is what makes proof proof. Evidence assembled by the team being audited is documentation of an assertion, not verification of a control.

The independence problem is structural. It does not go away by using better tooling to help the same team gather the same evidence more efficiently. It requires separating the observation of the control from the operation of the control. That separation is what an independent auditor provides for a SOC 2 audit. The same principle applies to the continuous evidence that sits underneath the audit — the record that the auditor reviews and the customer trusts.

04 / What the alternative looks like

The alternative is not a new category of software. It is a different operating model for how governance work gets done.

Observe controls at their source. In Salesforce, that means querying the system's own access configuration — not copying records out, but confirming the control state and recording the finding. In Microsoft 365, it means verifying that the relevant policies are active for the relevant user population. In Okta, it means confirming MFA enforcement rates against the full population of users in scope, not a sample. In AWS, it means confirming that logging is active, that encryption settings meet the standard, that the configuration matches what the policy requires.

Record that each control was met. Timestamped. Covering the full population, not a sample selected by the team preparing for the audit. Hashed so that the record cannot be altered after the fact. Held independently, not in a system operated by the team being assessed.

Deliver proof, not data. The output of this process is not a dashboard with charts showing compliance percentages. It is a record that a specific control was verified at a specific time against a specific population, produced by an independent process, and held in a form that an auditor can rely on without needing to re-verify the methodology. That is what a compliance programme looks like when it is built to answer "can you prove it?" rather than "can you show you tried?"

05 / Why AI raises the stakes on both problems

AI governance makes both structural problems worse, not better.

On data possession: AI systems process your most sensitive content. Salesforce's Einstein and Agentforce features operate on your customer records. Copilot in Microsoft 365 operates on your email, your documents, your Teams conversations. Gemini in Google Workspace operates on your files and your calendar. Governing these systems well requires understanding their configurations, their data-access scopes, and their output behaviours. If you do that by copying AI-processed records into a compliance tool, you have added a downstream copy of the content those AI systems touched — compounding the data-possession problem across the most sensitive layer of your stack.

On self-grading: AI governance is new enough that the frameworks are still being written. NIST's AI RMF is voluntary. The EU AI Act is complex and its enforcement will take time to mature. In that environment, the temptation is to declare AI governance done on the basis of internal assessment — a policy document, a register assembled by the team that operates the systems, a set of screenshots showing that the right settings are toggled. That is exactly the self-grading problem at the moment it matters most. The organisations that will be in a strong position when AI governance obligations sharpen are the ones that already have independent, continuous evidence rather than point-in-time internal assertions.

AI also accelerates the pace at which the systems under governance change. A Salesforce administrator who enables a new Agentforce capability, a Microsoft tenant where Copilot access is expanded, a Google Workspace configuration that changes when a new product launches — these are not changes that a quarterly review will catch. The evidence programme has to run at the pace the systems change, not the pace the audit cycle permits.

06 / Governance as a service

Software tools do not solve the independence problem. An independently-operated process does. That is the case for governance as a service — not a platform you license and operate yourself, but a firm that takes ownership of the governance outcome and operates the continuous evidence programme on your behalf.

The distinction matters. When you operate a compliance tool yourself, the evidence it produces is still your evidence, gathered by your process, subject to the same self-grading critique. When a firm operates an independent evidence programme against your systems — observing controls at their source in Salesforce, Microsoft 365, Okta, and AWS; recording findings; holding the record independently — the output has a credibility that internally-produced evidence cannot match. The firm is accountable for the accuracy of the record, not just the operation of the tool.

This is where business governance is going — past the GRC category entirely — because it is the only architecture that resolves both structural problems at once. It eliminates data possession by observing at source and holding zero copies of underlying records. It eliminates self-grading by separating the observation of controls from the operation of controls. It answers "can you prove it?" with proof rather than with documented assertions that someone else must take on faith.

The mid-market companies that move to this model now will find the next enterprise deal, the next audit, and the next regulatory inquiry materially easier to navigate. Not because their controls are necessarily better, but because their proof is. In a landscape where AI governance is tightening, where customer security reviews are becoming more rigorous, and where the cost of getting it wrong compounds with every breach and every deal that stalls — the question of whether you can prove it is not an audit formality. It is a business question. The answer should be yes.