# SOC 2 Readiness Assessment

**Version 1.0 — April 18, 2026**
**Operator:** Chaz Landry, WiseBoard
**Framework:** AICPA Trust Services Criteria (2017, with 2022 points of focus). Targeted criteria for initial Type I: **Security** + **Availability** + **Confidentiality**. Privacy added at Type II once SCC patterns settle.

This is a **self-assessment** to identify the gaps between WiseBoard's current control posture and what a SOC 2 Type I audit would require, and to set a partner + timing for that audit.

## Scoring legend

- ✅ **In place** — control documented, implemented, evidence available.
- 🟡 **Partial** — control exists but evidence collection or formal documentation is incomplete.
- ❌ **Gap** — control not yet implemented; remediation needed before Type I.

## Common Criteria — summary

| CC | Criterion | Status | Evidence / gap |
|---|---|---|---|
| **CC1.1** | Demonstrates commitment to integrity and ethical values. | 🟡 | Operator code of conduct documented; needs annual signed acknowledgment workflow once team grows. |
| **CC1.2–CC1.5** | Board oversight, structure, accountability. | 🟡 | Sole-operator structure; will require formal advisory structure before Type II. |
| **CC2.1–CC2.3** | Information & communication, internal/external. | ✅ | Trust Center, customer DPA, runbook, status page, security@ alias. |
| **CC3.1–CC3.4** | Risk assessment & fraud risk. | 🟡 | Annual risk assessment scheduled — first formal pass to be completed before audit kickoff. |
| **CC4.1–CC4.2** | Monitoring of controls. | 🟡 | Vendor-neutral observability layer in place (`lib/observability`); Sentry hook ready. Quarterly control-monitoring cadence to be formalized. |
| **CC5.1–CC5.3** | Control activities. | ✅ | Documented in Security Overview + Incident Response Runbook. |
| **CC6.1** | Logical/physical access — boundaries, identification, authentication. | ✅ | bcrypt password hashing, role-based access, 2FA on all admin accounts, single-tenant logical isolation by `userId`/`organizationId`. |
| **CC6.2** | Authorize, modify, remove access. | ✅ | Single-operator with documented offboarding plan; access reviews quarterly. |
| **CC6.3** | Restrict access to data and physical assets. | ✅ | Data access requires authenticated session; production DB credentials held only by operator. |
| **CC6.4** | Manage points of access. | ✅ | All access through Replit Deployments + managed PostgreSQL; no shared accounts. |
| **CC6.5** | Discontinue logical/physical access. | ✅ | Force-signout + credential rotation procedures documented in Incident Response. |
| **CC6.6** | Protect against external threats. | ✅ | Edge TLS, HSTS, rate limiting on telemetry, dependency audit on each release. |
| **CC6.7** | Restrict transmission of data. | ✅ | TLS 1.2+, no plaintext data over public networks. |
| **CC6.8** | Detect and act on unauthorized software. | 🟡 | Dependency audits run; formal allowlist for production dependencies pending. |
| **CC7.1** | Detect & respond to anomalies. | ✅ | Observability layer with `slow_request` and error events; per-IP rate limiting. |
| **CC7.2** | Monitor system components. | ✅ | Status page health checks for `/`, `/api/health`, classroom, mobile. |
| **CC7.3** | Evaluate security events. | ✅ | Incident severity tiers + response times defined in runbook. |
| **CC7.4** | Respond to security incidents. | ✅ | Runbook published. |
| **CC7.5** | Recover from identified incidents. | ✅ | RPO 24 h / RTO 8 h documented; quarterly restore drill scheduled. |
| **CC8.1** | Change management — authorize, design, implement, document. | ✅ | All production changes via Replit Deployments + version control; commit messages capture authorship and intent. |
| **CC9.1** | Identify, develop, implement risk-mitigation activities. | 🟡 | Risk register to be formalized before audit. |
| **CC9.2** | Assess and manage vendor and business-partner risks. | ✅ | Subprocessor list + change policy + DPAs with each subprocessor. |

## Availability criteria (A series)

| Criterion | Status | Evidence |
|---|---|---|
| A1.1 — capacity demand monitored | ✅ | Replit Reserved VM sizing reviewed monthly. |
| A1.2 — environment protections (recovery, backup) | ✅ | Daily encrypted backups; 30-day retention. |
| A1.3 — recovery from failure tested | 🟡 | First quarterly restore drill scheduled May 2026. |

## Confidentiality criteria (C series)

| Criterion | Status | Evidence |
|---|---|---|
| C1.1 — information identified and protected | ✅ | Schedule of Data in DPA Exhibit B; encryption at rest + in transit. |
| C1.2 — confidential info disposed | ✅ | 30-day deletion window + cryptographic destruction of backups. |

## Critical gaps before Type I

1. **Formal annual risk assessment** (CC3.1) — schedule first pass with chosen audit partner.
2. **Quarterly control-monitoring evidence collection** (CC4) — automated via compliance-automation partner.
3. **Restore drill evidence** (A1.3) — execute first drill May 2026, capture artifacts.
4. **Production-dependency allowlist** (CC6.8) — formalize current `pnpm audit` workflow into a tracked allowlist.

## Recommended path

| Step | Recommendation | Target |
|---|---|---|
| 1 | Choose compliance-automation partner. **Vanta** preferred (best K-12 vendor pattern), **Drata** acceptable backup, **Secureframe** for cost-sensitive path. | When ARR ≥ $200k from district contracts |
| 2 | Engage CPA firm for SOC 2 Type I (3-month observation window). | After 90 days on the partner platform |
| 3 | Move to Type II (12-month observation) when district pipeline justifies. | 12 months after Type I report issuance |

## Trigger to start

WiseBoard will engage a compliance-automation partner and begin formal Type I work when district-tier ARR exceeds **$200,000/year** (≈ 8–10 district contracts at current pricing). At that revenue, the audit cost (~$15–25k Type I, $30–50k Type II) is a single-digit percentage of ARR and the controls maturity will be naturally higher.

In the interim, this self-assessment, the Security Overview, the Incident Response Runbook, and the executed DPA collectively give district IT-security teams enough to approve WiseBoard for pilot and pilot-to-paid conversion.

— *Chaz Landry, Operator, WiseBoard*