--- type: entity title: SOC 2 Compliance Dashboard aliases: - compliance dashboard - SOC2 dashboard - Trust Services Criteria dashboard modified: 2026-04-07 tags: - compliance - soc2 - governance - dashboard - adoption-case category: product --- # SOC 2 Compliance Dashboard > The live governance evidence dashboard at `/compliance-dashboard.html`. Five SOC 2 Trust Services Criteria mapped to production code paths, four live compliance metrics, and a one-click JSON evidence export for SOC 2 auditors. The CTO's single most important verification artifact. ## What it is A live HTML page at `public/compliance-dashboard.html` on the Preston-Test repo and at `/compliance-dashboard.html` on the live demo site. Built with Alpine.js + Tailwind, the page renders five collapsible SOC 2 TSC panels, four live metric cards, and a regulatory timeline showing upcoming enforcement dates. An evidence export button POSTs to `/api/compliance/export` and downloads a JSON package with reasoning traces + AI costs + audit actions for a given date range. Per [[sources/09-claim-proof-matrix]], this page is the proof artifact for claim #3 ("Governance evidence is live") with the verification action "expand SOC2 sections and export evidence." A CTO reviewing the package is expected to click through each of the five panels and actually try the evidence export. ## Why it matters (to the adoption case) For a CPA firm and its audit-heavy clients, SOC 2 compliance posture is non-negotiable. This dashboard is what turns the "compliance evidence export and SOC 2 mappings" ask from [[pages/role-briefs/cto|the CTO role brief]] from an abstract request into a specific URL with specific controls. The CTO can literally open the page, expand each TSC category, and see the implementation backed by source-code paths. It's also the **live answer** to the CTO brief's question about whether SOC 2 mapping exists as a real document (not just a summary slide). It does — and it points at source code paths so the CTO can audit the actual implementation. ## The 5 SOC 2 Trust Services Criteria panels All five categories are marked **"Implemented"** on the dashboard. ### CC6 — Security (Logical & Physical Access Controls) | Control | Implementation | Source | |---|---|---| | JWT Authentication | Token-based auth with production secret validation | `src/middleware/auth.ts` | | RBAC Permissions | Role-based access control on all sensitive endpoints | `src/middleware/rbac.ts` | | Timing-Safe API Key Validation | `crypto.timingSafeEqual` prevents timing attacks | — | | Rate Limiting | Enforced in production; fail-fast guard on misconfiguration | — | | Production Guards | JWT_SECRET validation, demo-mode blocking, rate-limit enforcement at startup | — | ### A1 — Availability (Recovery & Continuity) - **Health Check Endpoints** — `/health` for load balancer and Kubernetes probes - **Circuit Breaker Pattern** — Automatic failure isolation for external service calls - **Disaster Recovery** — Documented recovery procedures with RTO/RPO targets - **Auto-Scaling** — Kubernetes Helm chart with 2-10 replica scaling (Helm + Terraform IaC per [[sources/04-technical-proof]]) ### PI1 — Processing Integrity (Accuracy & Completeness) - **AI Confidence Scoring** — Every mapping includes a 0-100 confidence score with breakdown (see [[pages/concepts/oracle-comparison]] for the live example) - **Hallucination Detection** — GovernanceService validates AI output against known schemas - **Schema Drift Blocking** — Syncs blocked on critical drift; structured `SCHEMA_DRIFT_BLOCKED` result code (first formally-ingested result code for the Schema Drift Shield) - **Reasoning Traces** — DB-persisted step-by-step AI decision audit trail (matches the Reasoning Trace Engine from the four safety mechanisms) ### C1 — Confidentiality (Information Protection) - **DLP/PII Detection** — the dashboard dynamically renders the pattern count and list. When authenticated, it fetches live from `/api/compliance/dlp-patterns`. When unauthenticated (the typical reviewer experience), it shows a **14-pattern snapshot**: SSN, credit card, email, phone, intl phone, medical record, IP address, API key, JWT, bank account, DOB, passport, driver's license, name. A `[snapshot]` badge appears in snapshot mode. Of these 14, **10 have confirmed regex implementations in DLPService.ts** and `name` is in GovernanceService.ts (11 confirmed). DOB, passport, and driver's license are not found as regex patterns in the code and may be behind the live API endpoint or represent planned additions. See [[pages/concepts/production-proof]] "DLP pattern count — reconciled" for the full analysis. **Note**: earlier wiki claims of "8 patterns" came from a stale NotebookLM scrape, not the live dashboard — the actual HTML snapshot says 14. - **Sensitive Data Masking** — Shared `maskSensitiveData()` utility strips PII from all log output - **Encrypted Credential Storage** — Connector credentials encrypted at rest via ConnectorCredentialService ### P1 — Privacy (Notice, Consent & Retention) - **GDPR/CCPA Compliance** — DLP service designed for EU and California privacy regulations - **Audit Trail Logging** — Every AI action logged with user ID, timestamp, and action type - **Data Retention Policies** — Configurable retention with **90-day default purge cycle** ## Live compliance metrics (four stat cards) The dashboard fetches live data from `/api/compliance/summary` and displays four metrics: | Metric | Source | Time window | |---|---|---| | Reasoning Traces | DB-persisted sessions | All time | | AI Cost Total | $ across all providers | Last 30 days | | Audit Actions | Session-scoped event log | Since startup | | Compliance Rate | Actions passing governance | % (current) | ### Demo fallback values When the dashboard is accessed without authentication (the typical reviewer scenario), it falls back to representative snapshot values with an explicit "Snapshot" badge: - **42** reasoning traces - **$3.87** AI cost - **156** audit actions - **97.4%** compliance rate Reviewers need to know they're in snapshot mode — there's a "Representative snapshot" vs "Live API data" indicator at the top. Authenticated demo mode is required for the evidence export to actually produce a live download. ## Evidence export The **Export Evidence Package** button (green, prominent) triggers a `POST /api/compliance/export` with a 30-day date range by default. The response is a JSON package covering reasoning traces + AI costs + audit actions, downloaded as `compliance-evidence-YYYY-MM-DD.json`. In demo/snapshot mode, the export shows an authentication-required message instead of downloading. The "evidence package exported and reviewed" Gate Metric #4 from [[sources/13-pilot-30-60-90]] maps directly to clicking this button and reviewing the downloaded file. ## Regulatory timeline (shown on the dashboard) | Law | Enforcement Date | Scope | |---|---|---| | **EU AI Act** | August 2, 2026 | Full enforcement of high-risk AI system requirements (transparency obligations, conformity assessments, post-market monitoring) | | **Colorado AI Act (SB 24-205)** | June 30, 2026 | Developers and deployers of high-risk AI systems must use reasonable care to prevent algorithmic discrimination | Both dates are displayed with a "days until" countdown badge on the live dashboard. ## The "Built by Auditors" framing Three callouts at the bottom of the page explicitly tie the governance work to Squire's CPA-firm identity: - **CPA-Grade Audit Trails** — *"Every AI decision is logged with user, timestamp, inputs, outputs, and confidence score — the same rigor Squire applies to client engagements."* This is the **strongest explicit Squire framing** in any ingested source. - **SOC 2 Alignment from Day 1** — *"All five Trust Services Criteria mapped to production code. Not a retrofit — compliance was a design requirement from the first commit."* - **Evidence Export in One Click** — "Download a structured JSON evidence package covering reasoning traces, AI costs, and audit actions — ready for your SOC 2 auditor." The tagline at the top of the page — *"SuiteCentral 2.0 — Built by Auditors, for Auditability"* — is consistent with [[sources/oracle-comparison]]'s footer. Same branding across the two governance-proof pages. ## Why the source code paths matter Three of the five SOC 2 panels cite specific source files: - `src/middleware/auth.ts` — JWT Authentication - `src/middleware/rbac.ts` — RBAC Permissions - `crypto.timingSafeEqual` — referenced inline (standard Node.js crypto module) A reviewer can open these files directly in the Preston-Test repo to verify the implementation. This is the dashboard's design making "trust by looking" feasible — it's not asking the reviewer to believe a claim; it's pointing at the code that backs the claim. ## Sources - [[sources/compliance-dashboard]] — primary source, the full dashboard content with 5 SOC 2 panels, live metrics, regulatory timeline, and Built by Auditors callouts - [[sources/09-claim-proof-matrix]] — this dashboard is the proof artifact for claim #3 ("Governance evidence is live")