Architecture Audit for Telehealth SaaS — Catch HIPAA Risk Before Audit
Read your telehealth SaaS against the HIPAA Security Rule before a customer's compliance reviewer does. Fixed $5-8K, 1-2 weeks, severity-tagged report and recorded walkthrough.
The problem
A telehealth SaaS at the point of its first real enterprise deal arrives at a specific kind of wall. The product works. Patients show up, clinicians take calls, money moves. But somewhere in the data flow there is typically at least one place where ePHI is doing something the founder did not intend — riding in a webhook payload that gets logged to a non-BAA logging service, sitting in an error tracker's breadcrumb, going out in a PagerDuty SMS, getting joined to a customer ID in an analytics tool, or being copied into a queue that runs on infrastructure no BAA has been signed against. None of these are visible from the product side. All of them are visible the first time a customer hospital's security team runs a serious diligence pass.
Latent ePHI in third-party paths
The expensive failure mode at this stage is finding out about these gaps during the deal cycle. A questionnaire comes back with eleven items the founding engineer cannot answer cleanly, the customer's compliance reviewer asks for a data-flow diagram and a BAA inventory, and the deal slips a quarter while engineering scrambles to close findings that have been latent for a year. The shape of the work is rarely catastrophic — most findings have small remediations — but the timing is. Closing fifteen findings under deal pressure in three weeks is roughly four times as expensive in engineering time and founder attention as closing the same fifteen findings on a normal cadence.
Silent audit-log and retention drift
The other expensive failure mode is the silent compliance drift. 45 CFR 164.312(b) requires every system that contains or uses ePHI to have audit controls — hardware, software, or procedural mechanisms that record and examine activity. Most telehealth SaaS codebases launch with audit trails on the obvious tables (visits, prescriptions, messages) and slowly accumulate new tables that hold ePHI in a derivative form without ever getting added to the audit-trail inventory. By month nine the audit-log coverage map and the actual ePHI footprint have drifted apart, and nobody on the engineering team has the full picture in their head anymore. 45 CFR 164.530(j) compounds it — documentation and records must be retained for six years from creation or last effective use — which means a retention policy designed against a one-year SaaS norm is quietly out of compliance and the founder doesn't know it.
What changes for your business
The audit gives a senior engineer who has shipped multi-tenant SaaS inside HIPAA programs one to two weeks with your codebase and 30 minutes with each system owner, and produces three artifacts: a written report with every finding tagged by severity and by the specific Security Rule section it touches, a recorded screen-share where the report gets read with you and your lead engineer so the context lands, and a prioritized list of the next six weeks of work that would matter most before your next compliance touchpoint. The audit ends when the report lands, not when an hourly meter runs out.
Fixed-cost read against the Security Rule
For your business, this is a fixed-cost way to find the HIPAA-breach-class issues in your codebase before a customer's compliance reviewer does, and to find the latent §164.312(b) and §164.530(j) drift before it shows up in an OCR enforcement action. The audit reads the same layers a senior engineer would read on day one of a fractional CTO engagement, but with the extra lens that every system boundary gets traced against the HIPAA Security Rule, the BAA graph, and the actual ePHI footprint inside the database. The deliverable is in language your engineers can act on Monday morning AND in language your Privacy Officer and your auditor can take to a customer compliance reviewer without a translation layer.
Severity bands tied to specific regulations
Findings come back in four severity bands, each tied to a specific regulation where it applies. Critical findings are breach-class or BAA-violation class — PHI in a webhook payload that gets logged to a non-BAA service, a vendor in the data path without a signed BAA per §164.308(b), a database table holding ePHI with no audit trail against §164.312(b), patient identifiers in alert text routed through non-BAA channels, an RLS policy that lets one tenant read another tenant's visits. High findings are decisions that will fail a serious enterprise security review or force a painful migration — encryption posture that cannot support per-tenant keys or BYOK without a rebuild, multi-state data residency that does not match your stated posture, retention policies that conflict with §164.530(j)'s six-year floor, licensure-routing logic that does not match the state list you operate in. Medium and Low cover the long tail — audit-trail fields that should be richer, observability gaps you'll wish for during incident response, dependency hygiene, BAA inventory that should be tracked as a first-class document.
Walkthrough that lands with engineering and compliance
The recorded walkthrough matters more on a telehealth audit than on a generic SaaS audit because the audience is wider. A written report alone gets read by the lead engineer and forgotten. A 60 to 90 minute screen-share with the founder, the lead engineer, and (often) the Privacy Officer creates a shared mental model that all three roles can refer back to when the next customer questionnaire arrives or the next architectural decision touches ePHI. The recording, the report, and the codebase annotations are yours to keep regardless of what happens next.
What the audit looks for that is telehealth-specific
Five reading lenses run on top of the standard architecture audit, each tied to a specific failure mode that costs telehealth SaaS founders deals or causes compliance findings.
PHI in webhook payloads and metadata. Stripe, Twilio, SendGrid, segment-style analytics pipes, error trackers, and internal webhook fan-outs all carry payloads that may contain ePHI by accident. The audit traces every outbound and inbound payload in both directions and names anywhere a patient identifier, MRN, diagnosis code, visit timestamp joined to a patient, or clinical note is crossing a boundary it should not cross. Stripe specifically does not sign BAAs, which means the architecture has to keep Stripe outside the HIPAA boundary entirely — opaque visit tokens in metadata, no PHI in description fields, no clinical context in webhook bodies. The audit confirms whether that boundary holds.
BAA scope gaps against §164.308(b). Every vendor that touches ePHI on your behalf must be inside a signed BAA. The audit builds the BAA graph from the actual data flow — not from the BAA folder — and names vendors that are touching ePHI without a signed BAA on file. The common offenders are transactional email providers, queue services, error trackers, log aggregators, analytics platforms, and customer-support tools that ingest message bodies. Each gap is flagged with the specific data flow that created the exposure and the remediation pattern (replace vendor, sign BAA, or move that data out of that vendor's path).
Audit-log gaps against §164.312(b). The audit inventories every table that holds ePHI in either canonical or derivative form, checks the INSERT/UPDATE/DELETE audit-trail coverage on each, and flags any table whose audit trail is missing, partial, or missing the actor identity. The deliverable is a table-by-table audit-log map your engineers can implement against, plus a recommendation on whether your current audit-log storage strategy (database table, dedicated log store, append-only ledger) is appropriate for your scale and your six-year retention obligation.
Encryption-in-tenant decisions and BYOK readiness. Encryption at rest and in transit are baseline; the audit reads them and confirms posture. The more interesting reading is whether the architecture can support per-tenant encryption keys or customer-managed BYOK without a rebuild. Enterprise customers — especially hospital systems and health-insurance plans — increasingly ask for BYOK as a condition of signing. The audit names whether your current architecture can deliver it inside six weeks of focused work or whether it has to be rebuilt first.
Multi-state data residency, on-call paging that exposes PHI, and §164.530(j) retention. Three smaller readings that catch high-cost mistakes. Multi-state residency: does the database actually segregate records per your stated posture, or does it co-mingle in a way a state regulator would flag. On-call paging: does the alert text routed through PagerDuty, Slack, SMS, or email carry patient identifiers through channels that aren't BAA-covered. Retention: does your auto-deletion policy conflict with the §164.530(j) six-year floor, or does it hold ePHI longer than the lawful basis supports.
How the engagement runs
Day one is a 30-minute kickoff. We confirm scope, get the access set up (read-only repo, read access to production dashboards, BAA inventory document if you have one), and schedule the system-owner conversations. Days two through six (or two through ten on a longer engagement) are the read — going through the codebase layer by layer with the HIPAA reading lens on top, and doing the 30-minute conversations with each system owner as findings surface. The Privacy Officer is welcome on the kickoff and the walkthrough; we don't need them for the daily read.
The final day is the walkthrough. The written report lands in your hands the morning of the walkthrough so you have time to skim it first. The walkthrough is 60 to 90 minutes on screen-share, recorded, with the founder, the lead engineer, and (usually) the Privacy Officer. From there, the engagement is complete. A follow-up call two weeks later is included in the fixed fee and is useful for telehealth specifically — questions tend to surface as the team starts implementing the remediations and runs into edge cases the report didn't anticipate.
The "no retainer required" piece holds on the telehealth side too. If the audit shows that the right next step is a build engagement to close Critical and High findings, we can scope that separately. If the right next step is a Privacy Officer search, a compliance partner referral, or a different senior contractor, the report will say so. The audit fee is the only cost and the deliverable stands alone.
Proof this read lands
BoostFrame Enterprise AI runs seven production multi-tenant applications on architecture patterns the audit reads against: Supabase with row-level security spanning every tenant, Stripe billing with idempotent webhook handlers and a dedup-keyed-on-event.id pattern, custom JWT with refresh-token rotation across the app suite, audit-trail tables on every table holding sensitive data, and a vendor inventory tracked as a first-class document. BFEAI is not a telehealth product, and we do not pretend it is — the HIPAA-specific reading lens is something we apply to your codebase against your existing compliance program, not something we bring in pre-built. What transfers is the architectural muscle memory: the patterns that work in production multi-tenant SaaS, the failure modes a senior engineer learns to read for, and the discipline of writing a finding in language the engineering team can act on Monday morning. The author is Bill Fackelman, co-founder and CTO of BoostFrame Enterprise AI.
Outcomes you should expect
What this delivers
- Find PHI leaking into webhook payloads, alert messages, or third-party metadata fields before a customer compliance reviewer flags it during diligence.
- Trace the BAA boundary against your actual data flow — and name the vendors quietly touching ePHI without a signed BAA on file.
- Get a §164.312(b) audit-log inventory tied to specific tables and event types your engineers can act on Monday morning.
- Land the next BAA-bearing deal without losing six weeks to a security questionnaire that surfaces problems you could have caught in week two.
- Walk away with a severity-tagged written report and recorded walkthrough you keep — whether or not we continue past the audit fee.
Industry data
By the numbers
45 CFR 164.312(b) requires covered entities and business associates to implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information — an Audit Controls standard the audit specifically tests against in your event logs and database tables.
45 CFR 164.530(j) requires covered entities to retain documentation — including policies, written communications, and records of actions or designations — for six years from the date of its creation or the date when it last was in effect, whichever is later, which means retention-and-deletion policies for ePHI logs and backups have to be designed against a six-year floor.
Under 45 CFR 164.502(b), covered entities and business associates must make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose when using, disclosing, or requesting it — the principle the audit applies to every payload that crosses a third-party boundary, including webhook bodies and alerting messages.
45 CFR 164.308(b) requires covered entities to obtain satisfactory assurances through a written business associate contract before permitting a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity's behalf — meaning every vendor that touches ePHI must be inside a signed BAA, and the audit traces the BAA boundary against the actual data flow.
Stripe does not sign Business Associate Agreements and is not HIPAA-eligible — Stripe can only be used in telehealth SaaS under the HIPAA payment-processing carve-out, which requires that no PHI (patient names, dates of birth, diagnosis codes, clinical notes, MRNs) enter Stripe's systems through metadata, descriptions, or webhook payloads.
Live in production today
The same engineering, shipped in production at BFEAI.
I'm co-founder & CTO of Be Found Everywhere (BFEAI), a 7-app AI SaaS platform running today. The work I deliver for clients is the work I do every week on my own platform.
7
Production apps
200K+
Keywords generated
1,500+
AI scans run
7,000+
Sites automated
Common questions
What buyers ask before reaching out
How is this different from the generic SaaS architecture audit on the parent page?
The structural deliverable is the same — fixed fee, 1-2 weeks, severity-tagged written report, recorded walkthrough, prioritized next-six-weeks list. The reading is different. A telehealth-specific audit reads every system boundary against the HIPAA Security Rule and the BAA graph, not just against generic SaaS failure modes. Findings get tagged with the specific regulation they touch — §164.312(b) audit controls, §164.502(b) minimum necessary, §164.308(b) business associate contracts, §164.530(j) retention — so your Privacy Officer and your auditor can act on the report directly without a translation layer.
What kinds of telehealth-specific findings come up most often?
Five patterns show up on most first audits. PHI in webhook payloads — a Stripe or Twilio webhook handler that logged the full body to a non-BAA logging service, or an internal webhook fan-out that included patient identifiers downstream consumers don't need. BAA scope gaps — a vendor in the data path (a transactional email service, a queue, an error tracker, an analytics tool) that is touching ePHI without a signed BAA. Audit-log gaps against §164.312(b) — tables holding ePHI with no INSERT/UPDATE/DELETE audit trail, or a trail that's missing the actor identity. On-call paging that surfaces patient names or visit details in alert text routed through non-BAA channels. And retention policies that conflict with §164.530(j)'s six-year floor — either auto-deleting logs too soon or holding ePHI longer than the lawful basis supports.
Do I need an existing HIPAA program before booking this audit?
You need to be heading toward one. The audit reads your architecture against the Security Rule, but it doesn't replace a Privacy Officer, a risk analysis on file, or signed BAAs with your infrastructure vendors. If you're pre-launch and don't yet have those pieces, the audit is still useful — it surfaces the engineering work that has to happen before the compliance program closes — but the report will explicitly name the policy and risk-analysis work as out of scope and recommend you bring a healthcare-fluent compliance advisor in parallel.
We're about to sign a BAA-bearing enterprise deal. How fast can the audit close?
1-2 weeks of calendar time is the standard window. If the deal is pressing and the codebase is single-app under ~30K LOC, a 1-week sprint is workable with kickoff Monday and walkthrough Friday of the following week. The faster window costs the same flat fee — the cost driver is codebase scope, not calendar speed. What it gives you is a clean read on whether the questionnaire your customer's security team will send back has surprises you can pre-empt, or whether the architecture is already in a defensible shape.
What does the audit say about Stripe, given Stripe does not sign a BAA?
It traces every Stripe payload in both directions and confirms no PHI is crossing the line — no patient names or MRNs in description fields, no diagnosis codes in metadata, no clinical context in webhook bodies the consumer doesn't immediately discard. Stripe is usable for telehealth billing under the HIPAA payment-processing carve-out, but only if the data boundary holds. If the audit finds PHI leaking into Stripe, that's a Critical finding with a specific remediation — usually a metadata schema rewrite plus a webhook handler change that pulls clinical context from BAA-covered systems on the consumer side instead of from the Stripe payload.
Does the audit cover multi-state data residency and licensure routing?
Yes, as a High-severity reading. A telehealth visit legally takes place where the patient is sitting at appointment time, which means your licensure-routing logic, your provider-availability rules, and any state-restricted data storage decisions have to actually match the state set you operate in. The audit reads the routing logic against the state list, checks that the database doesn't co-mingle state-restricted records in a way that conflicts with your stated residency posture, and flags any state-specific consent flows that aren't wired up. It doesn't write your licensure policy — that's your compliance partner's work — but it tells you whether the code matches the policy you've already set.
Will the audit flag encryption decisions we have to make per-tenant?
Yes, and it's a common High finding. Encryption-in-tenant — where each customer hospital or clinic group gets its own key or its own encrypted column set — is a decision that gets harder to reverse the longer it's deferred. The audit reads your current encryption posture (at-rest, in-transit, and key management), tells you whether the architecture as built can support per-tenant keys later without a migration, and flags any place where a single shared key is doing work a customer's security team is going to ask hard questions about. If your enterprise customers are asking for BYOK (bring-your-own-key), the audit names whether your current architecture can deliver it or has to be rebuilt first.
What does the audit recommend for on-call paging that involves PHI?
The recommendation depends on what's currently in the alert text. If alerts include patient identifiers, visit IDs that can be joined back to patients, or any clinical context, the audit flags it as a Critical or High finding depending on the channel — patient name in a PagerDuty SMS that routes through a non-BAA telco is harder to defend than the same name in a Slack message inside a BAA-covered workspace. The remediation pattern is usually: alert text carries only opaque incident IDs, and the on-call engineer opens a BAA-covered internal tool to see the actual context. The audit names the specific alerts to rewrite and the channels to swap.
Is the audit useful if our customer just sent us a 200-question security questionnaire?
Often yes. The audit isn't a substitute for filling out the questionnaire, but the findings map closely to the questions a serious enterprise security team will ask — audit logging, encryption posture, BAA coverage, data-flow diagrams, vendor inventory, retention policy, breach response. Founders who run the audit before answering a long questionnaire usually find the questionnaire faster and less surprising. The report itself often satisfies several of the questionnaire's evidence asks directly.
Ready to see if this is a fit?
A 15-minute call. No deck, no slides. We talk about what you're shipping and where engineering is the bottleneck. Either way, you walk away with a senior engineer's read on your situation.