Compliance & Auditing: Evidence as a Side-Effect

SchemaBridge Team · 2026-01-24 · Compliance, SOC2, GDPR, Security

Making SOC2 evidence collection and GDPR erasure easier with a recorded execution history, and being precise about what it does not guarantee.

The Compliance Tax: Why Audits Slow You Down

If you have ever been through a SOC2, ISO27001, or HIPAA audit, you know the pain. The auditor asks: "Show me evidence that every user offboarding request was processed within 24 hours."

In a traditional system, this triggers a frantic scavenger hunt.

You search email logs.
You grep through Splunk for some "Deleted User" message.
You take screenshots of a JIRA ticket.
You cross-reference timestamps in a spreadsheet.

This manual evidence gathering can eat weeks of engineering time. It is the Compliance Tax. It distracts your best people from building features. And worse, the evidence is often circumstantial. You can prove a script ran, but can you prove exactly what data it touched?

The Audit Trail: Evidence as a Side-Effect

At SchemaBridge, we believe that evidence should be a side-effect of Execution, not a separate activity. The engine writes an audit trail as it works: execution starts, replays and operator resolutions, changes to workflows, vertices and edges, deployments, configuration and retention changes, permission and role changes, and approval decisions.

What the Trail Gives You

Recorded State Transitions: Run state itself lives in PostgreSQL and is updated as a run progresses; alongside it, every state transition is appended to an execution trace, so "how did we get here" is answerable after the fact. The audit trail records the run's start and any operator action on it, not every transition.
Traceability: For any run, you can inspect each step's recorded input and output (within your retention window). Note the distinction: Replay in SchemaBridge re-runs a workflow under a new execution, side effects included; it is not a read-only historical playback.
Queryable History: The audit trail is queryable per workspace and per workflow through the API, and it lives in a dedicated columnar store (ClickHouse, behind an internal audit service), separate from the operational database.

What It Is Not

Be precise with your auditor about the guarantees. The audit trail is application-append-only, not tamper-evident: there is no hash chain or signing, and audit writes are best-effort, so a write failure is not surfaced as a detectable gap. If you need WORM-grade evidence, export the trail to write-once storage that you control.

GDPR and the "Right to be Forgotten"

One of the hardest challenges in any history-keeping system is the "Right to be Forgotten" (Article 17 of GDPR). If you keep a history, how do you delete a user's PII (Personally Identifiable Information)?

Erasure and Retention

SchemaBridge approaches this with erasure paths and retention windows.

1. Erasure: Deleting a workspace runs a dedicated erasure path, backed by an obligation ledger that is recorded before the irreversible delete and verified afterwards; a separate path erases an individual user's data.

2. Automated Purging: Retention windows are set per workspace (or inherited from your plan). Aged execution rows, traces and payloads are deleted automatically.

3. Credential Masking: Credential-shaped fields (API keys, secrets, tokens) are masked as in run logs. PII masking is not* automatic, so the best defence is not to carry personal data through steps that don't need it.

Automating SOC2 Evidence Collection

You can use SchemaBridge workflows to automate parts of the audit itself.

The "Auditor Bot"

Instead of manually collecting screenshots, you create a specialized "Evidence Collection" workflow that runs on a cron schedule every Monday.

1. Scan: It queries the GitHub API to list all PRs merged last week.

2. Verify: It checks if each PR has an "Approved" review from a code owner.

3. Snapshot: It builds a JSON snapshot of the compliance status.

4. Archive: It writes the snapshot to storage your auditors can read (via an HTTP endpoint you control—ideally write-once storage).

When the auditor arrives, you point them at the archive instead of a pile of screenshots, and audit prep time shrinks accordingly.

{
  "week": "2026-W03",
  "mergedPullRequests": 42,
  "withCodeOwnerApproval": 42,
  "exceptions": []
}

Illustrative Scenario: Patient Onboarding in a Regulated Environment

Consider a hypothetical HealthTech startup that needs to automate patient intake forms.

The Challenge

They need to show that:

1. Only authorized staff could change or run the intake workflow.

2. Every change to the workflow and every run outcome was recorded.

3. Data was never exposed to third-party logging tools (Splunk/Datadog).

The Approach

1. Role-Based Access: Workspace roles (admin, writer, reader) and permission scopes limit who can edit, deploy and run the workflow, and every role change lands in the audit trail.

2. Recorded Runs: Each intake run's start and any operator resolution are in the audit trail, its full status history lives in the run history, and each step's payload is inspectable inside the platform rather than printed to stdout.

3. The Gaps They Would Still Own: SchemaBridge does not log who viewed a payload, has no HIPAA-specific role, and holds no HIPAA certification. Per-view access logging and the regulatory paperwork would remain their responsibility.

The Likely Payoff

A setup like this would make the change-management and run-history parts of an audit far less painful, while being honest about the parts the platform does not cover.

Comparison: Traditional Logging vs. SchemaBridge Audit Trail

| :--- | :--- | :--- | :--- |

Expert Checklist for Compliance Architecture

1. Don't Log PII: Be careful what you print to stdout, and what you pass between steps. Keep personal data out of payloads that don't need it.

2. Automate Evidence: If you do it manually, you will make a mistake. Script the audit.

3. Separate Duties: The person who writes the workflow should not be the person who holds the admin keys.

4. Test the Deletion: Regularly run "Mock GDPR Requests" to verify that your erasure and retention paths are actually working.

5. Know Your Platform's Limits: Ask every vendor—including us—exactly what is recorded, for how long, and whether it is tamper-evident. Write the answers into your control narrative.

Conclusion: Trust is an API

Compliance isn't about paperwork; it's about Trust. By building your systems on a foundation of recorded, queryable history—and by being precise about what that history does and does not guarantee—you move from "Trust me, I'm a good engineer" to "Here is the evidence."

Part of our Building the Bridge series. See also: The Future of Integration.