Fractional CTO · HIPAA
Fractional CTO for HIPAA-compliant software
Where PHI lives, who can touch it, and what your logs can prove — worked out in the architecture, not in a security review.
The case
HIPAA engineering is not generic engineering.
HIPAA work usually shows up the same way: the product works, and then a deal, an audit, or a 200-line security questionnaire asks something the architecture can't answer. Which vendors touch PHI, and under what agreement. Whether access control lives in the data layer or just in the application code. Whether the logs can say who looked at a specific record, and when. My angle on it: the platform I run as fractional CTO — Preventa Wellness, doing AI analysis over retinal images — is a wellness product that isn't required to meet the full rule. We engineered it to the highest standards anyway: encryption, access control at the data layer, audit trails written to be read by someone who is checking. That's the standard I hold this work to. I'm the engineering side, not the law firm — my job is making the system able to prove things, so the questionnaire gets answered with mechanisms instead of adjectives.
A compliance consultant tells you what the rule requires; making the system actually do it is engineering. Access control at the data layer, audit trails that stay queryable under pressure, de-identification pipelines, BAAs mapped to real data flows rather than a vendor list. That's CTO work done once and done right — not a standing full-time seat. And the boundary, stated plainly: I'm an engineer, not counsel. I build the controls; your lawyer owns the interpretation.
The first 90 days
What a hipaa engagement actually looks like
A fractional CTO for the engineering side of HIPAA makes the system able to prove what the questionnaire asks — PHI boundary, BAA coverage, access control, audit trail — so answers point at mechanisms instead of adjectives.
- 01
Weeks 1–2: Audit the system as built
Map what the running system actually does with PHI — every collection, every vendor, every log line — and diff it against what the policy documents claim. The gaps that matter live in that diff, not in either half alone.
- 02
Weeks 3–4: Close the vendor surface
Execute BAAs where a vendor must stay in the PHI path, and design the others out of it — routing stack traces away, scrubbing payloads, moving analytics onto de-identified data. Exceptions that cannot be removed get documented with the reason, not waved through.
- 03
Weeks 5–8: Make access and audit provable
Move authorization checks to the data layer — custom claims, row-level policies — so a missed check in application code cannot leak a record. Make the audit trail answer per-record questions (who, what, when) with retention that meets the six-year rule without a runaway bill.
- 04
Weeks 9–12: Answer the review with the system
Walk the security questionnaire control by control, pointing each answer at the mechanism that implements it. Then hand your team the map, so the next review is a walkthrough instead of a project.
What we cover
HIPAA-specific decisions I help you make
Tools I use in hipaa
Not ready to talk yet
The HIPAA architecture checklist
A free, ungated walk-through of the PHI boundary, the vendor surface, authorization, and audit trails — the four decisions every questionnaire eventually asks about. Read it before our first call; it is most of the agenda.
Read it →Request a triage
Talk through your hipaa problem.
Free, 30 minutes. Tell me where you're stuck — I'll tell you what it takes. I confirm every request within 24 hours.
FAQ
HIPAA questions founders ask
Are you a HIPAA compliance consultant? +
No — engineer-side only. I design and build the controls: the PHI boundary, access control, audit trails, the BAA-mapped vendor stack. Regulatory interpretation belongs to your counsel; my job is making the system match what that interpretation requires. The HIPAA architecture checklist says the same about itself: an architecture document, not a compliance instrument.
You said your own platform doesn't have to meet HIPAA. Why should I trust you with mine? +
Because the discipline transfers, and the reasoning is the point. Preventa Wellness handles sensitive health imagery as a wellness product, so the full rule doesn't bind us — we engineered it to the highest standards anyway, because the habits (encryption, access control, audit trails) are cheap to build in and brutally expensive to retrofit the first time a partner or enterprise customer asks. Building to a standard you're not forced to meet is the same muscle as building to one you are.
Can you HIPAA-certify our product? +
There is nothing to certify against — HIPAA has no regulator-issued certification for software, and anyone selling one is selling something the rule does not define. What exists is a defensible architecture: a documented risk analysis, implemented safeguards, and answers that trace to mechanisms. That is buildable, reviewable, and honest.
We already have a live product. Is it too late? +
No, but it costs more than doing it early — and the first job is finding out how much more. A $2,500 Technology Health Check covers exactly that: two weeks, written findings ranked by severity, and it doubles as the as-built audit this work starts from. Fixing access control and audit trails in a running system is normal engineering; it just has to be sequenced.
Does an audit trail really need six years of retention? +
The documentation retention requirement under the Security Rule is six years — and how you store logs decides whether that is a line item or a runaway bill. What to retain, what to sample, and how to keep queryability without keeping everything hot is written up in the audit-trail design piece on the blog, from a system that runs it.