tools / record
SOC 2 Readiness Tools
▶ Live demo — soc2.eponymic.org — the readiness survey. (The authority-mapper is a reviewed prototype, not yet deployed.)
Most SOC 2 guidance is written for companies that already have a security function. A ten- or twenty-person SaaS company facing its first audit has none of the scaffolding the framework quietly assumes — no named control owners, no readiness process, no compliance staff. These are two small tools aimed at exactly that gap: a readiness intake survey (the front door) and an org-authority mapping tool (the substance). Both are deliberately minimal, and both are built on the same discipline.
The survey — proportionate by design
The survey captures a firm’s readiness intent and hands back a package, manually fulfilled. What’s interesting about it isn’t the form; it’s what I didn’t build. I rejected a database-plus-auth app stack (Railway / Neon / accounts) — the right architecture for a platform with persistent multi-user state, and exactly what a separate, larger project of mine correctly uses — because a one-time lead-capture form has no persistent state for that machinery to manage. It’s pure client-side, email via a hosted form service, with a built-in honeypot for spam. And I chose ungated, visible disclosure over a consent checkbox, because this is lead capture, not a research study collecting data for analysis — the consent gate that’s genuinely required in my education-research project would be friction theater here.
That’s the whole point of the survey as an artifact: right-sizing infrastructure and consent to the actual need, and being able to say precisely why each heavier option was the wrong tool for this job. Status: scaffolded and deploy-ready, relocating onto my own domain.
The authority mapper — the SOC 2 gap most tools skip
SOC 2 assumes an organization has named roles: asset owners, control owners, approvers, the person who signs off. A small company has never assigned them, and assigning them is itself a deliverable. This tool takes a firm’s real job titles and maps them to authority roles — producing the co-signer and approver structure the framework expects to already exist.
What makes it a compliance tool rather than a guess is how it handles the judgment calls:
- An ambiguous title gets flagged, not silently resolved. “CPO” could be Chief People Officer or Chief Product Officer; the tool keeps a sensible default but marks it low-confidence so a wrong guess is cheap to correct — instead of quietly filing a product exec into the people-authority lane.
- A real choice gets surfaced, not defaulted away. When both an executive and a named finance role could own financial-systems approval, the tool shows a picker and makes the unchosen one a co-signer — rather than hardcoding a preference and hiding the decision.
- An unowned gap is marked, not papered over. The offboarding-notification trigger — who tells the technical owner that someone left — is left as a visible placeholder, because that gap (“nobody owns it”) is a real finding, not something to fake a value for.
Status: a reviewed, corrected prototype. Working through it, I found and fixed real defects — a column-misalignment bug, unreachable dead code, a duplicate rule shadowing another — the ordinary evidence that it’s a built thing, not a mockup. It isn’t deployed yet.
The rule underneath both
Across these and ReadySafe, the discipline is one sentence: never default silently to the
safe-looking answer. An unresolved branch renders unresolved, not a guess; an ambiguous
title renders a flag, not a confident mis-tag; an unowned duty renders a gap, not a filled
box. In compliance that’s the entire game — a tool that quietly picks the safe answer is
precisely how a firm ends up believing a gap is handled when it isn’t. Loud, never silent.
What this demonstrates
SOC 2 domain fluency — knowing which parts of the framework assume infrastructure a small org lacks, and building for that gap specifically. Proportionate engineering judgment — right-sizing infrastructure and consent to the real need, and being able to defend why the heavier option was wrong here. And honest handling of ambiguity — surfacing the judgment calls instead of burying them in a default. Those are the traits that separate someone who ships defensible compliance tooling from someone who ships a checkbox.
See the survey live: soc2.eponymic.org