What HIPAA and SOC 2 actually require from a customer portal

Here’s a conversation we have more often than you’d think.

A company is planning a customer portal — patient scheduling, benefits lookup, claims status, document exchange, take your pick. Someone on the team says, “We need it to be HIPAA compliant and SOC 2 certified.” Everyone nods. The requirement gets typed into the RFP. And then… nobody can say what that actually means for the login screen, the database, the analytics tags, or the support workflow.

That’s not a knock on anyone. HIPAA and SOC 2 are two of the most name-dropped and least understood frameworks in digital product work. One is a federal law with civil penalties attached. The other is an audit framework you choose to pursue. They overlap in spirit, diverge in mechanics, and both have very specific opinions about how your portal should behave.

So let’s demystify it. Here’s what each framework actually requires from a customer portal, what’s changing in 2026, and the traps we see teams fall into again and again.

First, the thing everyone gets wrong

HIPAA is a law. SOC 2 is a report.

You can’t be “SOC 2 certified” in the legal sense — SOC 2 is an attestation from a CPA firm that your controls, measured against the AICPA’s Trust Services Criteria, are designed well (Type I) and operating effectively over a period of months (Type II). It’s voluntary, but in practice it’s the price of admission for selling B2B software: enterprise buyers increasingly won’t sign without it.

HIPAA, on the other hand, isn’t optional and doesn’t come with a certificate. If your portal creates, receives, stores, or transmits electronic protected health information (ePHI) — even indirectly — you’re either a covered entity or a business associate, and the Security Rule, Privacy Rule, and Breach Notification Rule apply to you. There is no badge to earn. There is only compliance, demonstrated through documentation, safeguards, and (if you’re unlucky) an investigation by the HHS Office for Civil Rights.

Here’s the strategic insight most teams miss: the two frameworks are complementary, not redundant. SOC 2 gives you a mature, audited control environment. HIPAA tells you specifically how to handle health data within it. A portal built for both isn’t doing double the work — done right, it’s one architecture answering two sets of questions.

What HIPAA actually requires from your portal

Strip away the legalese and the HIPAA Security Rule asks your portal to do a handful of concrete things:

• Know who’s logging in — and prove it. Unique user IDs for every person. No shared “frontdesk@” accounts. Authentication strong enough to match the risk, which in practice means multi-factor authentication. MFA is technically still “addressable” under the current rule, but OCR’s enforcement actions have made its position clear: credential-based breaches without MFA are very hard to defend.

• Show only what each user is entitled to see. Role-based access control isn’t a nice-to-have — the “minimum necessary” principle is core to HIPAA. A billing coordinator shouldn’t be able to browse clinical notes. A patient should never, under any circumstance, be able to see another patient’s record because of a fat-fingered URL parameter (more on that later).

• Encrypt everything, everywhere. TLS in transit, encryption at rest. Like MFA, encryption has historically been “addressable,” but unencrypted ePHI is already the fastest route to a reportable breach.

• Log what happens and keep the logs. Audit controls are a required specification. Your portal needs to record who accessed what, when, and from where — and someone needs to actually review those logs, because “we had logging but never looked at it” is a recurring theme in enforcement actions.

• Have a plan for when things break. Session timeouts, automatic logoff, data backup, disaster recovery, and a breach notification process that can move fast — HHS requires notification within 60 days for breaches affecting 500+ individuals, and the proposed rule updates would tighten internal expectations dramatically.

• Paper the relationships. If a vendor touches ePHI on your behalf — hosting, email, analytics, chat, transcription, anything — you need a Business Associate Agreement (BAA) with them. No BAA, no data. This one sentence eliminates a shocking number of popular SaaS tools from your stack, and pretending otherwise is where a lot of portals quietly go out of compliance.

---

Regulatory watch: Proposed HIPAA security rule updates

The HIPAA Security Rule is changing. HHS has proposed its biggest Security Rule update in over a decade. While the final timeline has shifted (currently expected around 2027), the proposal would make controls like MFA, encryption, asset inventories, penetration testing, and faster recovery expectations much more prescriptive.

Our recommendation: Build to the proposed standard today. It’s far easier than retrofitting a live customer portal later.

---

What SOC 2 actually requires from your portal

SOC 2 is organized around five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security — the “Common Criteria” — is mandatory in every audit. The rest are scoped in based on what you promise customers and what your buyers demand.

For a customer portal, the Security criteria translate into familiar territory: logical access controls, MFA and least-privilege access, encryption in transit and at rest, change management (no cowboy deploys to production), vulnerability management, monitoring, and incident response. If you’ve built the portal to HIPAA’s standard, you’ve already laid most of this foundation.

The strategic decisions live in the optional criteria:

• Availability matters if your customers depend on uptime — think a portal that clinicians or claims processors use all day. It brings uptime monitoring, tested backups, and rehearsed recovery plans into audit scope.
• Confidentiality is the natural add-on for portals handling contracts, health data, or financial records.
• Processing Integrity matters when the portal does things — processes payments, calculates benefits, submits claims — and an error would be costly.
• Privacy is scoped less often than founders expect; many teams satisfy privacy obligations through Security and Confidentiality controls plus a standalone privacy program, adding the Privacy TSC only when a specific enterprise buyer demands it.

Here’s the scoping wisdom in one line: add a criterion when a meaningful share of your customers require it, and not before. Every additional criterion adds auditor hours, evidence collection, and cost. Over-scoping burns budget; under-scoping loses deals. Survey your actual buyers instead of guessing.

One more distinction worth internalizing: a SOC 2 Type I report is a snapshot (“controls are designed properly today”), while a Type II covers an observation window of typically 3–12 months (“controls actually operated”). Enterprise buyers overwhelmingly want Type II. Plan your product timeline accordingly — you can’t backdate an observation period.

We’ve reviewed a lot of portals over the years. The failures are rarely exotic. They’re the same handful of mistakes, on repeat.

Where teams get tripped up

1. The tracking pixel time bomb. This is the big one right now. Marketing adds Meta Pixel, GA4, session replay, or a chat widget to the site — standard practice everywhere else — and suddenly patient behavior data is flowing to an advertising platform with no BAA in place. OCR has made browser-based tracking one of its most active enforcement areas, and it isn’t theoretical: Kaiser’s 13.4-million-record exposure came from advertising pixels on its own websites, not from hackers. If your portal (or even the public pages around it) touches health context, every third-party script needs an inventory, a justification, and either a BAA or an exit.
2. Treating authorization as an afterthought. Authentication gets all the attention; authorization causes the breaches. Insecure direct object references — where changing /records/1234 to /records/1235 shows you someone else’s data — remain one of the most common portal vulnerabilities in the wild. Every data request needs a server-side check: is this user allowed to see this specific record? Not “is this user logged in.”
3. Assuming the cloud provider’s compliance is your compliance. AWS, Azure, and GCP will all sign BAAs and hold SOC 2 reports. That covers their half of the shared responsibility model. Your misconfigured S3 bucket, your over-permissioned IAM roles, your unencrypted database snapshot — those are yours. “We host on a HIPAA-eligible cloud” is the beginning of the story, not the end.
4. Logging without looking. Both frameworks require audit trails; both auditors and OCR investigators ask the follow-up question: who reviews them? A log nobody reads satisfies neither. Build review into someone’s actual job, with alerting for the events that matter — failed login bursts, privilege changes, bulk record access.
5. The compliance sprint. Teams treat SOC 2 as a two-week scramble before an enterprise deal and HIPAA as a checkbox in the statement of work. Both frameworks are fundamentally about sustained, evidenced operation — Type II audits measure months of behavior, and OCR’s active enforcement initiative specifically targets organizations whose risk analysis was missing, stale, or never acted upon. In 2025, OCR imposed 21 financial penalties, and risk analysis failures were the leading theme. Compliance is a rhythm, not a milestone.
6. Forgetting the humans. Support staff who verify identity loosely over the phone. Admin accounts shared “temporarily” that live forever. Offboarding that takes three weeks to revoke access. The portal can be a fortress and the process around it a screen door. Both frameworks explicitly cover workforce training, access reviews, and termination procedures — because attackers know the process is softer than the code.

The strategic takeaway: compliance as product advantage

Here’s the reframe that changes how teams approach this work.

The healthcare organizations reporting breaches to HHS in 2025 numbered over 770 — a record — with roughly 138 million records exposed. The average healthcare breach now costs more than $7 million. Against that backdrop, a portal that can demonstrate strong security isn’t a cost center. It’s a sales asset, a procurement accelerant, and a trust signal your competitors may not be able to match.

The practical playbook:

1. Design to the proposed HIPAA Security Rule now. The proposal would make MFA everywhere, encryption everywhere, real audit logging, tested recovery. When the final rule lands, you’ll be watching competitors scramble.
2. Scope SOC 2 around what your buyers actually ask for. Security always; Availability and Confidentiality usually; Privacy and Processing Integrity when the market demands them.
3. Inventory every third-party script and vendor touching user data. BAA or gone. Repeat quarterly — tag managers drift.
4. Build one control environment that answers both frameworks. The overlap between HIPAA safeguards and SOC 2 Common Criteria is enormous. Map controls once, collect evidence continuously, and let each audit draw from the same well.
5. Make someone own it. Compliance without an accountable owner decays. Fast.

A customer portal is where your organization’s promises become interface. HIPAA and SOC 2, for all their acronyms and audit language, are really just asking one question: can you keep the promises you’re making to the people who log in?

Build so the answer is yes — and provable.

---

Creed Interactive helps organizations design, build, and secure digital products that earn trust. Planning a portal that needs to satisfy HIPAA, SOC 2, or both? Let’s talk before the architecture hardens — that’s when the right decisions are cheapest.