SOC 2 Evidence, Produced by the Work Itself
Most tools ask you to go collect evidence. Fintra produces it: a governed authorization action maps to SOC 2 controls and writes hash-chained evidence automatically when the compliance loop is enabled.
Illustrative product view
Evidence as a byproduct of governance
The strongest concrete claim in Fintra’s compliance layer is the GOVERN→PROVE loop: a governed action produces the evidence that a control operated. When you authorize an action, a deterministic crosswalk maps it to the relevant SOC 2 controls, and ingesting the governed action writes an EvidenceItem plus a hash-chained TrustLedgerEntry with control links. The evidence is a byproduct of doing the work, not a separate collection project.
The deterministic SOC 2 crosswalk
| Action | Internal control | SOC 2 control |
|---|---|---|
| Authorization decision | AC-001 | CC6.7 |
| Logging the decision | LOG-003 | CC7.45 |
| OFAC / sanctions screen | REG-001 + VND-002 | Vendor / regulatory |
| Approver-over-limit | AC-003 | Access control |
So a single authorization-and-logging action automatically produces CC6.7 plus CC7.45 evidence - the mapping is deterministic (map_action_to_controls), so the same action always produces the same control evidence.
How evidence is emitted
From governed action to control evidence
- 1
Govern the action
The PDP returns a verdict for an authorization or logging action.
- 2
Emit (fail-soft)
emit_governed_action fires - fail-soft and idempotent on external_ref, a no-op unless a sink is configured.
- 3
Ingest
POST /internal/evidence/governed-action writes an EvidenceItem and a hash-chained TrustLedgerEntry.
- 4
Map to controls
The crosswalk links the evidence to the SOC 2 controls the action satisfies.
- 5
Surface for audit
The evidence appears in the control workflow and auditor views.
How it connects
- Built on the hash-chained trust ledger for tamper-evidence
- Feeds the same control library that tracks SOC 2 CC6/CC7
- Continuous compliance monitoring watches control health over time
- The auditor portal exposes the evidence to your assessor
Frequently asked questions
How does SOC 2 evidence automation work here?
When the compliance loop is enabled, a governed authorization or logging action is mapped by a deterministic crosswalk to SOC 2 controls - for example CC6.7 and CC7.45 - and ingesting the action writes an EvidenceItem plus a hash-chained ledger entry with control links. The evidence is produced by the act of governing the action, not collected separately.
Is the compliance loop on by default?
No. It is opt-in and dormant by default - it emits nothing unless a compliance sink is configured (via COMPLIANCE_SINK_URL or in-process mode). The engines exist and are tested; the wiring is deploy-time configuration, so it is accurate to describe it as working when enabled.
Which SOC 2 controls does an authorization action satisfy?
A deterministic crosswalk maps an authorization decision to AC-001 (SOC 2 CC6.7) and the logging of that decision to LOG-003 (SOC 2 CC7.45). So a single authorization-and-logging action automatically produces CC6.7 and CC7.45 evidence, and OFAC or approver-over-limit actions map to their own controls.
Is the evidence tamper-evident?
Yes. Each emitted evidence item is written alongside a hash-chained TrustLedgerEntry, so the evidence inherits the ledger’s tamper-evidence - an auditor can verify the chain to confirm the evidence was not altered after the fact.
Stay in the loop
One practical finance briefing a week - new guides, checklists, and benchmarks.
Let the work produce the evidence
Map governed actions to SOC 2 controls and write tamper-evident evidence when enabled.
Talk to us