There's a familiar quarterly ritual at most audit functions.
The audit team has just wrapped a SOX engagement. They have findings. They have test results. They have evidence. The findings reference controls that were tested. The test results reference risks the controls are designed to mitigate. Everything ties together — in the engagement workspace.
Meanwhile, the GRC team owns the controls catalog. They have the same controls listed there. They have the same risks listed in the register. They have their own tracking of which controls were last tested, which were deficient, which got remediated.
The two systems should agree. They almost never do.
So someone — usually a senior who already had a full week — sits down on Friday afternoon to reconcile. Pull the engagement test results. Pull the catalog last-tested dates. Cross-reference. Update the catalog where it lags. Note the disagreements. Email the audit lead about the ones that look weird.
This happens every quarter at most audit shops. It takes hours. The work product is a spreadsheet that gets archived and never looked at again. The next quarter, the same drift accumulates and the same reconciliation happens.
Most "GRC integration" pitches solve this by federating the two systems. Audit-management software talks to GRC software via API. Sync jobs fire on a schedule. Webhooks notify changes. There's a vendor whose entire product is a "single pane of glass" sitting on top of three other vendors' products.
Federation is what you do when you're stuck with two databases that don't trust each other. It works, kind of. It's also why the reconciliation ritual still happens — APIs lag, sync jobs fail silently, and the federated layer is one more thing to maintain.
The other option is to not have two databases.
Audvera does the unusual thing here. Engagement workspace and controls catalog aren't two products that talk to each other. They're two views of the same underlying graph.
Concretely: when an engagement scopes a risk, that risk is an entry in the canonical risk register. Not a copy of one. Not a "linked-to" pointer. The same row, queried with engagement context. When you're looking at the engagement workspace, you see this engagement's scoring and notes; the registry-side context is in a sidecar that's filterable to your access. When you're looking at the controls catalog, you see the same risk identity, plus an aggregated view of which engagements have touched it.
When a control gets tested in an engagement, the test result lives in the engagement's evidence ledger. The control catalog's "last tested" status is computed from that ledger — not maintained as a separate field that needs reconciliation. There's no drift to reconcile because there's no second copy.
When a finding is drafted, it's tied to the test step that produced it, the control the test step assesses, and the risk the control mitigates. The chain is a database join, not a status field.
This shift sounds incremental. It isn't. It's the difference between owning a graph and owning two databases that pretend to be one.
Three things change once the graph is one.
Reconciliation goes away. Not "reduces." Goes away. The Friday afternoon ritual disappears because there's nothing to reconcile. The catalog reflects the latest engagement evidence by definition.
Audit committee questions get faster answers. "Show me controls in our catalog that have been tested in the last quarter and produced a finding." That's a query against the graph, not a project. The CAE can pull it before the meeting starts.
The "shadow systems" problem disappears at its root. The reason audit functions accumulate spreadsheets and Notion pages and shared drive folders is that no system holds all the truth they need. When the data model is one graph, the spreadsheets stop being necessary. The team uses them because they have to, not because they want to.
A note on what this isn't.
It isn't an enterprise GRC platform. Audvera doesn't replace your privacy program, your vendor risk management tool, or your IT audit log aggregation. It's specifically about the audit function's working data — engagements, controls being tested, risks being assessed, findings being tracked. Inside that scope, it's one graph. Outside, it integrates the way every audit tool does — via export, file sharing, and the human workflow.
It also isn't continuous monitoring. The graph reflects what audit work has produced; it doesn't auto-populate from production telemetry. (That's a different conversation — and Audvera doesn't pretend to be that product.)
What it is, narrowly: the engagement workspace and the controls catalog see the same data, because they're querying the same model. Federation is what's avoided. The reconciliation tax goes to zero.
Two more scenarios where the graph-as-one shows up.
Promotion of an engagement risk. When an engagement discovers a risk that's not yet in the register, the system can either link to an existing register entry (if the fingerprint matches) or create a new register entry with provenance metadata. Either way, the risk identity is shared from the moment of creation forward. The next engagement that touches it — six months later, in a different business unit — sees this engagement's history.
The RCM lens, scoped to one engagement. Most controls catalogs have a Risk-Control Matrix view: rows of risks, columns of controls, cells indicating coverage and test status. That view is normally tenant-wide, which makes it nearly unusable for a specific engagement. Audvera's RCM view takes a engagement_id filter — same matrix, scoped to the controls and risks linked to one engagement. Uncovered risks show in red. Untested controls in amber. Failed tests red. Evidence gaps amber. The engagement lead opens this view and sees what's missing for the specific audit they're running, in the specific scope they're assessing.
That second one is impossible if the workspace and catalog are different databases. You can't filter a tenant-wide view by an engagement that lives in a different system. You can in Audvera because both views are queries on the same model.
Most audit-management products are an engagement workspace. Most GRC products are a control catalog. Audvera is the unusual case where they're the same thing seen two ways.
If your audit function spends time reconciling those views every quarter, the question isn't "how do we make federation work better." The question is "what would change if we didn't have to."
The reconciliation Friday goes away.
Two days a quarter back. Per senior. Across the function.
That's the small change. It also happens to be the structural one.