Fintra Trust feature
SOC 2 evidence, produced by the work itself
Fintra Trust, SOC 2 Evidence
Example figures- CONTROLS TOUCHED
- CC6.7 · CC7.45
- auto-mapped
- EVIDENCE ITEMS
- per action
- hash-chained
- LOOP
- opt-in
- when configured
- Authorization action, then AC-001 (CC6.7)
- evidence written
- Logging action, then LOG-003 (CC7.45)
- evidence written
- OFAC/sanctions check, then REG-001
- evidence written
- Approver-over-limit, then AC-003
- evidence written
- Sink not configured
- no-op (dormant)
Evidence as a byproduct of governance
The strongest concrete claim in Fintra’s compliance layer is the GOVERN to 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
Govern the action
The PDP returns a verdict for an authorization or logging action.
Emit (fail-soft)
emit_governed_action fires: fail-soft and idempotent on external_ref, a no-op unless a sink is configured.
Ingest
POST /internal/evidence/governed-action writes an EvidenceItem and a hash-chained TrustLedgerEntry.
Map to controls
The crosswalk links the evidence to the SOC 2 controls the action satisfies.
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
Questions people ask
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.
Keep reading
Guides
Calculators
One finance briefing a week
New guides, checklists and benchmarks, by email. Unsubscribe from any issue.
Let the work produce the evidence
Map governed actions to SOC 2 controls and write tamper-evident evidence when enabled.