# Fairvisor for SOC 2 & Compliance

URL: https://fairvisor.com/for/compliance/

---


 Audit 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.
See the compliance docs 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 governance RBAC with 6 Roles Viewer, Editor, Operator, Admin, Billing, Super Admin. Each role has precisely scoped permissions. Mapped to your identity provider via Zitadel. → Security model Kill-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 response Policy 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 rollout Signed 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 Pass your audit. Sleep at night. See the compliance docs Also relevant For SRE Sub-millisecond enforcement, graceful degradation, and SLO alerting.
For Platform Engineering Policy-as-config, GitOps-native, Kubernetes-ready rate limiting infrastructure.
For API-First SaaS Per-tenant limits, noisy neighbor protection, and tiered plan enforcement.