SOC 2 & HIPAA-ready software

The six-month bolt-on that kills the deal

Here is how it usually goes. You build the product. It works. It gets traction. Then a real customer shows up — the kind with a legal team and a procurement process — and they send you a security questionnaire. Two hundred and fifty questions. Do you have role-based access control? Do you log administrative actions? Where does customer data physically live? Can you produce a list of everyone who viewed a given record in the last ninety days?

And you can't answer most of it. Not because the product is bad, but because none of it was designed in. So now you're looking at a rebuild disguised as a "compliance project": retrofitting audit trails into an application that never had a concept of who did what, bolting authorization onto endpoints that assumed one kind of user, migrating data out of a region you picked because it was the default. Meanwhile the deal sits in procurement, and eventually your champion inside the customer stops fighting for you.

That's the failure mode this service exists to prevent. Compliance readiness is not a feature you add at the end. It's a set of architectural decisions — about identity, about logging, about where bytes live — that are cheap on day one and brutally expensive on day six hundred. Build it in from the start and the questionnaire becomes a filing exercise instead of a roadmap.

What "readiness" actually means, technically

Frameworks like SOC 2, HIPAA, and GDPR are written in the language of controls and policies, not code. Translating them into architecture is the actual work. Here's what that translation looks like in practice.

Audit logs

An audit log is not your application log. Application logs are for debugging and they get rotated away. An audit log is an append-only, tamper-evident record of security-relevant events: who authenticated, who changed a permission, who exported data, who read a record they don't normally read. It needs an actor, an action, a target, a timestamp, and enough context to reconstruct what happened without guessing.

The design decisions that matter: writing the log in the same transaction as the change so you can never have one without the other, making it structurally impossible for application code to delete or edit entries, and retaining it long enough to satisfy the longest window any framework asks for. Retrofitting this later means auditing every mutation path in the codebase and hoping you found them all. Designing it in means one write path and one guarantee. There's a full walkthrough in the SOC 2 audit logging guide.

RBAC

Role-based access control is the control auditors ask about first and the one most products fake. Real RBAC means authorization is a distinct layer with its own model — roles, permissions, resource scoping — enforced server-side on every request, not a set of if (user.isAdmin) checks scattered through route handlers and, worse, mirrored in the UI where hiding a button is mistaken for enforcing a rule.

It also means least privilege actually holds: a support agent can see the records they need to resolve a ticket and nothing else, and that boundary is expressed once, in code you can point an auditor at. When authorization lives in one place, "show us how you enforce least privilege" is a five-minute conversation. When it's scattered, it's a discovery project.

SSO

Enterprise buyers want SAML or OIDC single sign-on, and they want it for a reason that's about risk, not convenience: when they offboard an employee, that person needs to lose access to your product immediately, without anyone at your company doing anything. SSO — ideally with SCIM provisioning alongside it — is what makes that true.

The architectural implication is that your identity model has to allow for an external identity provider from the beginning. An application built around locally stored passwords, with users identified by an email column that doubles as the primary key, is painful to convert. One that treats identity as a linkable external concept converts easily. That decision costs nothing early and a great deal late.

Encryption at rest

Encryption at rest is usually the easiest control to satisfy and the one people over-explain. Managed databases and object storage from the major cloud providers encrypt volumes by default with keys managed by the platform, and for most SOC 2 scopes that's the answer. What matters is being able to state it precisely: which stores hold customer data, what encrypts each one, who holds the keys, and how they rotate.

Where it gets interesting is application-layer encryption for high-sensitivity fields, and key management when a customer asks about bringing their own key. Those carry real tradeoffs — encrypted fields can't be indexed or searched normally — and are worth deciding deliberately rather than under deadline.

Data residency

Data residency is the control that most often forces a rebuild, because it's the one that's hardest to change after the fact. GDPR makes it a live question for European customers; some healthcare and public-sector buyers have their own regional requirements. The question is simple to ask and hard to answer retroactively: for a given customer, where does their data live, and does it ever leave that region?

Answering it means knowing every place data comes to rest — primary database, replicas, backups, object storage, log aggregation, analytics, the queue, the email provider, every third-party subprocessor. Log and analytics pipelines are the usual leak: the database is pinned to the right region and a copy of every record is quietly flowing to a vendor somewhere else. Designing for residency early means picking regions consciously and keeping a subprocessor list that's true. Retrofitting means a data migration plus renegotiating vendor contracts.

"Compliant" and "audit-ready" are different words

This is the distinction worth being precise about, and the place where a lot of marketing copy — including from people who should know better — gets sloppy.

Building compliant architecture means the technical controls exist and work: the audit log is there, RBAC is enforced, SSO works, data is encrypted and lives where it should. That's engineering, and it's what I do.

Being audit-ready means those controls are documented, consistently operated, and evidenced over time — with written policies, defined owners, and a body of evidence a firm can sample. SOC 2 in particular is not a certification you buy; it's a report a licensed CPA firm issues after examining your controls. A Type I report describes design at a point in time. A Type II describes operating effectiveness over an observation window, commonly three to twelve months, which means you need history before you can even start.

HIPAA works differently again. There is no HIPAA certification at all — no government body issues one. There are requirements in the Security and Privacy Rules, business associate agreements with anyone who touches protected health information, and your own documented risk analysis. A vendor claiming to be "HIPAA certified" is telling you they don't understand the regulation.

So here's the honest framing of what this service is. I build the architecture that makes an audit passable and a security questionnaire answerable. I do not issue audits, I am not a CPA firm, and I don't sell certifications. When someone tells you a codebase is "SOC 2 certified," they're describing something that doesn't exist — software isn't certified, organizations are examined. Getting that language right matters, because the buyer's security team notices when you get it wrong, and it costs you credibility exactly where you need it.

What I will do is make sure that when you engage an auditor, the technical half of the work is already done and you're not discovering in week two that you need to rebuild authorization. The gap between "we have good architecture" and "we have a Type II report" should be policy work and elapsed time, not engineering.

How this works as an engagement

Same as everything else I do: $1,000 a day, flat. No hourly billing, no change orders for the compliance parts, no separate "security review" line item. A day is a full day on your thing.

In practice the work takes one of two shapes. If you're building something new and enterprise or healthcare buyers are in your future, we design the identity, authorization, logging, and data-locality model in from the start — which adds far less time than people expect, because these are decisions rather than features. If you already have a product and a questionnaire in your inbox, the first day is an assessment: what exists, what doesn't, what's genuinely blocking, and what the buyer will actually accept. That triage is often worth more than the implementation, because many questionnaire items are already satisfied by your cloud provider and just need to be written down correctly.

Either way you get the artifacts, not just the code: the data flow, the subprocessor list, the description of what's logged and retained for how long. That's the material your future auditor and your buyer's security team both need.

Go deeper

Two guides cover the technical detail this page deliberately doesn't duplicate:

• SOC 2 audit logging for developers — what to log, what not to log, schema design, retention, and tamper-evidence.
• SOC 2 vs. HIPAA: what maps and what doesn't — the overlapping controls, the ones unique to each, and why doing one doesn't get you the other.
• Building a HIPAA-compliant app on Next.js and Vercel — the concrete platform version, including which parts of that stack can carry PHI and which can't.

If you're staring at a questionnaire and want to know how bad it actually is, that's a good first conversation to have.