FAIRVISORAudit trail included. SOC 2 controls built in.
Immutable audit logs, RBAC with MFA, kill-switch with approval workflows, and full policy versioning. Fairvisor is built for companies that need to prove their controls work.
What Fairvisor Does for Compliance
Immutable Audit Log
Every policy change, every kill-switch activation, every bundle deployment — logged with who, what, when, and why. Exportable. Tamper-evident. → Platform governanceRBAC with 6 Roles
Viewer, Editor, Operator, Admin, Billing, Super Admin. Each role has precisely scoped permissions. Mapped to your identity provider via Zitadel. → Security modelKill-Switch with Audit Trail
Emergency freeze for any entity. Role-gated (Operator role or above). Logged with operator identity, reason, scope, and timestamp. Exactly what auditors want to see. → Kill-switch incident responsePolicy Versioning
Every policy change creates a new version. Full diff history. Rollback to any previous version. Know exactly what was enforced and when.Shadow Mode as Change Control
New policies are tested in shadow mode before enforcement. Show auditors: “We tested this on production traffic for 7 days before enabling it.” → Shadow mode rolloutSigned Policy Bundles
Policies are signed with HMAC-SHA256 before distribution to edge nodes. Tamper detection is built in. If a bundle is modified in transit, the edge rejects it and keeps the last-known-good policy.SSO Integration
(Enterprise) SAML/OIDC SSO for centralizing access control. Integrates with Okta, Azure AD, Google Workspace.Approval Workflows
(Enterprise, coming soon) Critical actions require approval from a second operator. Four-eyes principle, built in.What Auditors Ask
"How do you enforce rate limits?"
Declarative policies enforced at the edge, versioned in git or the SaaS UI. Every enforcement decision is logged and traceable to a specific policy version."Who changed this and when?"
Immutable audit log with operator identity, action, scope, and timestamp for every policy change, kill-switch activation, and bundle deployment."What happens if a tenant abuses your API?"
Kill-switch can freeze a targeted scope with a role-gated, audit-logged workflow. Logged with reason and exportable timeline for IR workflows."Where's the SOC 2 evidence?"
Six control mappings covering CC6, CC7, and CC8. Exportable logs and policy history ready for your auditor’s questionnaire.Who This Is For
- Security and GRC teams preparing for SOC 2 Type II audits
- Engineering leads who own the API governance narrative
- Enterprise SaaS companies with security-conscious buyers
- Teams where “who changed this policy?” needs a real answer
FAQ
Which SOC 2 criteria does Fairvisor address?
Six criteria: CC6.1 (logical access controls), CC6.3 (access revocation), CC7.2 (system monitoring), CC7.3 (change management), CC7.4 (incident response), CC8.1 (input boundaries). Pre-mapped to specific Fairvisor controls — not a checklist you have to interpret.What does the audit log capture?
Every policy change, kill-switch activation, and bundle deployment: operator identity, action, scope, reason, and timestamp. Immutable. Exportable via API in JSON or CSV format. Nothing is reconstructed after the fact.Can I export logs in a format my auditor accepts?
Yes. Logs are exportable in JSON and CSV. Filter by event type, time range, operator, or resource. Ready for auditor questionnaires without manual reconstruction or Slack archaeology.How does RBAC map to SOC 2 CC6.1?
Six roles (Viewer, Editor, Operator, Admin, Billing, Super Admin), each with precisely scoped permissions. Operator and above required for policy deployment and kill-switch. Mapped to your identity provider via SAML/OIDC — so access follows your existing provisioning and de-provisioning process.What is shadow mode and why do auditors care?
Shadow mode runs a new policy against real traffic without enforcing it. You can show auditors: “We tested this policy on production traffic for 7 days before enabling it.” That’s change control evidence for CC7.3 — test before promote, documented and automatic.Can we keep evidence for each audit period without manual prep?
Yes. Filter audit exports by time range and event type (policy changes, deployments, kill-switch actions), then store them as period snapshots. This gives repeatable evidence packages for each quarterly or annual audit cycle.Why teams choose Fairvisor
Audit trail that answers every question
Immutable logs with who, what, when, and why for every policy change and enforcement action — exportable, not reconstructed after the fact.Controls that map to SOC 2 criteria
Pre-mapped to CC6, CC7, CC8 — not a feature checklist, a set of controls you can point auditors at directly.RBAC-protected emergency response
Kill-switch is role-gated (Operator+) and fully audit-logged with identity, reason, and timestamp — exactly the evidence auditors look for in CC7.4.SOC 2 Control Mapping
| SOC 2 Criteria | Fairvisor Control |
|---|---|
| CC6.1 — Logical access | RBAC, 6 roles, MFA for critical ops |
| CC6.3 — Access revocation | Kill-switch, token rotation |
| CC7.2 — System monitoring | Prometheus metrics, alerting, anomaly detection |
| CC7.3 — Change management | Policy versioning, shadow mode, audit log |
| CC7.4 — Incident response | Kill-switch, circuit breaker, forensic export |
| CC8.1 — Input boundaries | Rate limiting, budget enforcement, loop detection |