SOC 2 Type II Readiness — Gap-Analysis Workbook
Entity: Ordermatic, Inc. — ERP-Unlocked (AI order-processing platform)
Framework: AICPA Trust Services Criteria (2017, rev. 2022) — Security/Common Criteria CC1–CC9 in scope; Availability (A1) and Confidentiality (C1) noted.
Report type targeted: SOC 2 Type II (controls operating effectively over an observation window).
Date: 2026-06-25 · Status: DRAFT readiness gap analysis · Companion to: casa-self-assessment.md, compliance-roadmap.md
The one thing to internalize: Type II grades whether each control ran consistently for 3–6 months, with evidence. Most of our technical controls already exist (CASA proved it). Almost all of our gaps are organizational/process — policies, reviews, vendor management, IR — and those produce no evidence until they’ve been operating. So the long pole is calendar time, not engineering. Start the observation window the day the process controls exist, even if thin.
0. Readiness snapshot
Section titled “0. Readiness snapshot”| Control family | What it covers | Our state |
|---|---|---|
| CC1 Control Environment | Org, ethics, board, accountability | 🔴 Mostly missing (process/governance) |
| CC2 Communication & Information | Policies, security comms, external commitments | 🟡 Partial — code documented, no policy set |
| CC3 Risk Assessment | Risk identification, fraud, change-driven risk | 🔴 Missing — no formal risk register |
| CC4 Monitoring | Control monitoring, deficiency remediation | 🟡 CI gates monitor some controls; no program-level monitoring |
| CC5 Control Activities | Tech + process control selection | 🟢 Strong tech / 🔴 weak process |
| CC6 Logical & Physical Access | Authn, authz, provisioning, encryption | 🟢 Strongest — directly CASA-backed |
| CC7 System Operations | Vuln mgmt, monitoring, incident response | 🟡 Vuln mgmt strong; IR + detection thin |
| CC8 Change Management | SDLC, change approval | 🟡 PRs+CI exist; not formalized |
| CC9 Risk Mitigation | Vendor/subprocessor mgmt, business disruption | 🔴 Missing — no vendor risk program |
| A1 Availability | Capacity, backup, DR | 🔴 Mostly missing — primitives, no tested DR |
| C1 Confidentiality | Data classification, retention, disposal | 🟡 Retention classes in schema; no formal policy |
Headline: CC6 (the highest-risk family for a multi-tenant ERP holding PII + customer POs) is audit-strong today because of the CASA work. The readiness deficit is concentrated in CC1/CC3/CC9 and Availability — the people-and-paper controls a security-by-default codebase doesn’t produce on its own.
1. Common Criteria gap analysis (CC1–CC9)
Section titled “1. Common Criteria gap analysis (CC1–CC9)”Each row: Have (cite CASA control / repo mechanism) → Gap → Next step.
CC1 — Control Environment
Section titled “CC1 — Control Environment”| # | Have | Gap | Next step |
|---|---|---|---|
| CC1.1 | Eng norms in AGENTS.md / CLAUDE.md (no hand-written migrations, secrets via op/Infisical, feature-flag-gate ERP writes). Informal but real. |
No Code of Conduct / signed acknowledgment / documented ethics. | Adopt CoC + AUP; require signature on hire (platform-tracked). |
| CC1.2 | — | No management security-oversight cadence. | Name a security owner (founder/CTO); quarterly security review with minutes. |
| CC1.3 | Implicit role separation (deploy / prod access). | No org chart / roles / segregation-of-duties statement. | One-page org chart + roles doc; note SoD for prod deploy / secret access. |
| CC1.4 | — | No hiring/competence standards or background checks. | Add background-check step; document required competencies. |
| CC1.5 | CASA punch list shows remediation accountability. | Accountability per-project, not standing. | Tie control ownership to named people in the platform. |
Verdict: 🔴 Biggest pure-process gap. ~1–2 weeks of policy writing (templates) + naming an owner closes most.
CC2 — Communication & Information
Section titled “CC2 — Communication & Information”| # | Have | Gap | Next step |
|---|---|---|---|
| CC2.1 | Strong internal docs (AGENTS.md, patterns.md, CASA workbook, roadmap). | Eng docs, not a policy set. | Convert into the SOC 2 policy bundle (InfoSec, Access, Change, IR, Vendor, BCP/DR, Data Classification, AUP) — platform templates. |
| CC2.2 | — | No security-issue reporting channel; no awareness training. | #security channel + reporting path; annual training. |
| CC2.3 | CASA §1 lists 3P commitments. | No customer-facing security/privacy commitments. | Publish privacy policy + trust page; align to DPA work on roadmap. |
Verdict: 🟡 Documentation exists; needs reframing as policy + a customer-facing layer.
CC3 — Risk Assessment
Section titled “CC3 — Risk Assessment”| # | Have | Gap | Next step |
|---|---|---|---|
| CC3.1 | Implicit risk thinking in CASA workbook (IDOR/tenant isolation = “highest-risk family”). | No formal risk assessment (likelihood × impact). | One workshop → risk register (tenant data leak, forged-PO fraud, secret exposure, vendor outage, ERP-write error). |
| CC3.2 | CF-4 names a fraud vector: spoofed-sender forged-PO fraud (DMARC p=none on erpunlocked.com). |
Fraud risk not formally assessed. | Add fraud scenarios (forged PO, fraudulent ERP write, insider misuse of support-admin bypass). |
| CC3.3 | Change-risk partly handled: feature-flag gating for ERP writes, append/merge-only bronze. | Not documented as risk-assessment input. | Reference as mitigations; add “change introduces risk” to change policy (CC8). |
Verdict: 🔴 Missing as artifact, but raw material is unusually good. Half a day to formalize.
CC4 — Monitoring
Section titled “CC4 — Monitoring”| # | Have | Gap | Next step |
|---|---|---|---|
| CC4.1 | Automated control monitoring in CI: pnpm audit --audit-level=critical, new python-sca.yml, supply-chain gate. |
Monitors deps, not the control program. | Compliance platform with continuous control monitoring = CC4 automation. |
| CC4.2 | CASA punch list demonstrates deficiency tracking + remediation. | No standing review process. | Quarterly control review (folds into CC1.2 meeting). |
Verdict: 🟡 Best-positioned process family — CI does machine monitoring; needs a human review loop.
CC5 — Control Activities
Section titled “CC5 — Control Activities”| # | Have | Gap | Next step |
|---|---|---|---|
| CC5.1 | Deep bench of tech controls (CASA matrix §2). | Not mapped to risks (CC3) or written as policy. | Map each CASA control to a TSC criterion (platform crosswalk does ~80%). |
| CC5.2 | Tech controls deployed + enforced (CI gates, default-deny). | Process controls not deployed. | Deploy the policy bundle; assign owners. |
| CC5.3 | — | No annual policy re-deployment. | Annual policy review + re-acknowledgment in platform. |
Verdict: 🟢 tech / 🔴 process. Mapping is assembly, not invention.
CC6 — Logical & Physical Access (our strongest — CASA-backed)
Section titled “CC6 — Logical & Physical Access (our strongest — CASA-backed)”| # | Have (CASA citations) | Gap | Next step |
|---|---|---|---|
| CC6.1 | IDOR: every data path filters by clerkOrganizationId; default-deny in packages/auth/src/middleware.ts (CASA 3.1.1–3.1.4); support-admin bypass audited via SupportAccessAudit.logAccess(). |
Need it demonstrated over the window + an access-control policy. | Headline evidence; write the access-control policy. |
| CC6.2 | Authn delegated to Clerk (RS256/JWKS, packages/auth/src/server.ts); no first-party passwords. |
Provisioning/deprovisioning not formalized. | Document onboarding/offboarding; Clerk de-provisioning in offboarding checklist. |
| CC6.3 | Least-privilege server-side, role checks, feature-flag-gated ERP writes. | No periodic access review. | Quarterly access review across Clerk/GCP/Neon/Infisical/1P/Cloudflare/GitHub — start now (recurring evidence). |
| CC6.4 | All infra cloud (Cloud Run, Neon, R2). | Physical security inherited. | Collect subprocessor SOC 2 reports as inherited evidence (CC9 overlap). |
| CC6.6 | TLS everywhere (CASA 4.1.1); apps/internal behind Cloudflare Access; OAuth state in HttpOnly cookies. TLS-validation bypass rejectUnauthorized:false fixed (CASA P2). Open: HSTS (now in PR), DNSSEC off, Cloud Armor WAF absent. |
Close HSTS/DNSSEC; confirm WAF at the GCP edge. | See edge findings (CF-2/CF-3) + GCP audit. |
| CC6.7 | AES-256-GCM + PBKDF2-HMAC-SHA512 for ERP creds; R2 SSE; no weak crypto. | Provider-default at-rest encryption undocumented. | Document encryption posture in data-protection policy. |
| CC6.8 | Supply-chain gate; no eval/dynamic exec; MIME-allowlisted non-exec uploads. | Magic-byte validation a CASA P4 item. | Optional hardening; not a Type II blocker. |
Verdict: 🟢 Audit-ready by design. Work here is documentation + the recurring access review.
CC7 — System Operations
Section titled “CC7 — System Operations”| # | Have | Gap | Next step |
|---|---|---|---|
| CC7.1 | SCA in CI (Node pnpm audit + Python pip-audit); supply-chain cooldown gate. DAST (ADA Burp/ZAP) planned. |
No vuln-mgmt policy (remediation SLAs); DAST not recurring. | Vuln-mgmt policy (critical 7d / high 30d); schedule recurring DAST; bump the flagged Python CVEs. |
| CC7.2 | Cloud Logging; SupportAccessAudit; Better Stack/telemetry available. |
No centralized security alerting / anomaly detection; log retention undocumented. | Define security alerts (auth failures, support-admin bypass, failed ERP writes); document retention. |
| CC7.3–4 | IR is ad-hoc; MEMORY playbooks (secret-rotation, Neon pooler) are de-facto runbooks. | No formal IR plan. Hard Type II requirement. | IR policy (severity tiers, on-call, escalation, breach-notification clock, post-mortem). Run one tabletop in-window. |
| CC7.5 | Recovery primitives (Neon PITR, redeploy, idempotent processing). | Recovery untested/undocumented. | Folds into BCP/DR (A1). |
Verdict: 🟡 Vuln mgmt strong; incident response is the critical gap — mandatory, currently informal, needs a tabletop in-window.
CC8 — Change Management
Section titled “CC8 — Change Management”| # | Have | Gap | Next step |
|---|---|---|---|
| CC8.1 | PR-against-staging workflow (never commit to staging/main), CI gates, conventional commits, Drizzle-generated migrations, feature-flag-gated ERP writes, append/merge-only bronze. | Not formalized as a control; PR review not a written/enforced policy. | Change-mgmt policy + branch protection on main/staging (require review + passing CI) → automatic audit evidence. Cheapest high-value win. |
Verdict: 🟡 Practice mature; proof isn’t. Branch protection + policy → near-instant coverage.
CC9 — Risk Mitigation
Section titled “CC9 — Risk Mitigation”| # | Have | Gap | Next step |
|---|---|---|---|
| CC9.1 | — | Business-disruption mitigation / cyber-insurance status unknown. | Confirm cyber-liability insurance; document it. |
| CC9.2 | Subprocessor inventory in substance (CASA §1: Clerk, Stripe, Google, WhereFour, P21, Neon, R2, GCP, Infisical, 1Password); secrets segregated. | No vendor risk program: no collected SOC 2s, DPAs, annual review, public subprocessor list. | Vendor register; collect subprocessor SOC 2/ISO reports (inherited evidence); sign DPAs; annual review. |
Verdict: 🔴 Missing as a program, but inventory already enumerated in CASA §1 — fill-in-the-table.
2. Cross-cutting process controls (gate the Type II window)
Section titled “2. Cross-cutting process controls (gate the Type II window)”None produce evidence until they’ve been operating.
| Process control | Status | Next step | Window-critical? |
|---|---|---|---|
| Security policy set | 🔴 None | Platform templates; founder signs; team acknowledges | Yes — Day 1 |
| Risk assessment + register | 🔴 None formal | One workshop; CASA + CF findings seed it | Yes — annual |
| Vendor/subprocessor mgmt | 🟡 Inventory in CASA §1 | Register + subprocessor SOC 2s + DPAs | Yes — annual |
| Change management | 🟡 Practice yes, policy no | Branch protection + written policy | Partial |
| Incident response | 🔴 Informal | IR policy + one tabletop in-window | Yes — operating instance |
| Periodic access reviews | 🔴 None | Quarterly across all systems — start now | Yes — most recurring evidence |
| Onboarding/offboarding | 🟡 Implicit | Checklists; tie to HR trigger | Yes — every hire/exit is a sample |
| Security awareness training | 🔴 None | Annual training | Yes — completion records |
| BCP/DR | 🔴 None | Doc + one DR test (Neon PITR restore) | Yes — operating instance |
| Control monitoring | 🟡 CI-level only | Platform agents + quarterly human review | Yes |
The pattern: controls that “need an operating instance” (access review, IR tabletop, DR test, offboarding) are why a Type II can’t be compressed. Each must happen ≥once, observed, inside the window. Schedule them in month 1.
3. Availability (A1) and Confidentiality (C1)
Section titled “3. Availability (A1) and Confidentiality (C1)”Commit to Security + Confidentiality at minimum (we hold PII + PO data); add Availability only if procurement demands it (adds DR burden).
A1 — Availability: Cloud Run autoscaling + Neon serverless give primitives; gaps are documented capacity planning, RTO/RPO, and a tested DR plan (run a Neon PITR restore drill in-window). The bronze append/merge-only rule (never replace) is an availability + integrity safeguard — cite it.
C1 — Confidentiality: retention classes (retain_30d / keep_forever) implement a retention policy already; tenant isolation (CC6.1) is the core control; PAN/CVV scrubbing keeps cardholder data out (CASA 6.5.1). Gaps: formal data-classification + retention policy docs, and a documented disposal process. PCI overlap: formalize the “no cardholder data in scope” decision — the WhereFour PAN-scrub is the control.
4. Fastest path to audit-ready
Section titled “4. Fastest path to audit-ready”Step 1 — Pick the platform (week 1): Vanta, Drata, or Secureframe. For a small eng-led team on this stack, Vanta or Drata (both auto-connect GCP/GitHub/Clerk/cloud infra + run continuous control monitoring = CC4). Pick on price + integration coverage for Clerk/Neon/Infisical; they’re interchangeable for SOC 2.
Step 2 — Start the Type II observation window NOW (the long pole): 3–6 months of operating evidence; the clock can’t be compressed. Minimum to start: policy bundle adopted + signed, platform agents connected, recurring controls scheduled and first instance run (first quarterly access review, first offboarding checklist, branch protection on). Start thin — a 3-month window starting now beats a “perfect” program starting in Q4.
Step 3 — Reuse CASA evidence (parallel): map into the platform’s TSC crosswalk — tenant isolation → CC6.1/6.3; Clerk authn → CC6.1/6.2; TLS + AES-GCM/PBKDF2 → CC6.6/6.7; SCA in CI → CC7.1; no-credential-logging → CC6.7/C1; secrets in Infisical → CC6.1; PR-to-staging + CI → CC8.1; CASA subprocessor list → CC9.2.
Step 4 — Close in-flight technical gaps (parallel): bump the flagged Python CVEs, add HSTS (in PR), enable DNSSEC, tighten DMARC to reject (anti-fraud). Small + already scoped.
Step 5 — Build the process controls (weeks 1–6): by window-criticality — access review → IR plan + tabletop → vendor register + subprocessor SOC 2s → risk register → onboarding/offboarding → BCP/DR + restore drill → security training.
Step 6 — Collect inherited evidence: SOC 2/ISO reports for GCP, Neon, Cloudflare, Clerk, Stripe, Infisical, 1Password → covers physical security (CC6.4) + seeds CC9.2.
Step 7 — Engage the auditor early (most platforms broker one) so they bless the control set before the window closes.
Shortest honest timeline
Section titled “Shortest honest timeline”- Month 0: platform live, policies signed, agents connected, clock starts, first access review done, branch protection on.
- Months 1–3: controls operate; run the IR tabletop + DR restore drill; bump CVEs/HSTS/DNSSEC/DMARC; assemble CASA → TSC mapping; collect subprocessor reports.
- Month 3 (min) – 6: window closes; auditor fieldwork; Type II report issued.
Bottom line: CC6 is already audit-strong from the CASA work. The gap is process (CC1/CC3/CC9, IR, access reviews) and the calendar. The single highest-leverage action is to start the observation window now with a thin-but-real control set, then thicken it while the clock runs — the clock is the only thing you can’t buy back.