There's no single government "HIPAA certification" that a product receives — compliance is an ongoing program covering technical, administrative, and physical safeguards, not a one-time badge. Protocol is architected with HIPAA's technical safeguards in mind from the ground up, including encryption, strict access controls, and network isolation for all systems that touch patient data

How is patient data protected at rest and in transit?

1. All patient data is encrypted at rest within Azure-managed storage and databases and encrypted in transit using TLS.
2. Patient file storage runs on a dedicated storage account, separate from other application data, accessible only through managed identities — not shared keys or credentials.

How is network access to patient data restricted?

1. Core services (application backend and database) run behind Azure private endpoints, meaning they are not reachable over the public internet.
2. All network traffic is routed through Protocol's private virtual network by design.
3. Development and production environments run in fully separate Azure subscriptions, so test activity can never reach real patient data.

How are user identities and logins handled?

1. Authentication is handled through Auth0, an industry-standard identity provider, using token-based (JWT) verification on every request.
2. Organizations using Protocol can be configured with isolated, co-branded access, keeping each customer's users and data logically separated.

How is access to infrastructure and backend systems controlled?

1. Services authenticate to each other using managed identities rather than passwords or shared keys, and each identity is granted only the specific permissions it needs to do its job (least-privilege access).
2. Infrastructure is defined as code and version-controlled, so every change to the environment is reviewed and auditable rather than made by hand.

HIPAA Compliance FAQ

What Protocol already does to protect patient data, what is still being finished, and what only your organization can decide.

The short version

1. Protocol has strong technical safeguards in place: role and facility access control, full audit logging, encryption, and monitoring.
2. A number of items are still open before production PHI go-live, notably signed BAAs, a web firewall, and formal policies.
3. No software is “HIPAA certified.” Compliance is a combination of the platform, its configuration, and your organization’s own processes.

The basics

Where Protocol stands overall.

Is Protocol HIPAA compliant?

Protocol is built to support HIPAA compliance, and most of the technical safeguards are live. It is not yet complete: several administrative and vendor items are still open (see Open items), and those need to be closed before real PHI goes into production.

HIPAA has no official certification. Anyone claiming a product is “HIPAA certified” is using marketing language.

What counts as PHI in Protocol?

Any health information tied to an identifiable person. In Protocol that includes patient demographics, SSNs, encounter notes, mental status and risk assessments, billing statements, and uploaded patient documents.

Which HIPAA rules does this cover?

1. Security Rule: technical, physical, and administrative safeguards for electronic PHI. Most of the engineering work lives here.
2. Privacy Rule: who may use or disclose PHI, and patient rights such as an accounting of disclosures.
3. Breach Notification Rule: notifying affected people within 60 days of discovering a breach.

What is the current status at a glance?

Access & audit

Who can see what, and the record of who did.

Who can see a patient’s record?

Only signed-in users whose role and facility permit it. Each endpoint checks both, and the checks fail closed: if the rules do not clearly grant access, the request is denied. Roles include Admin, Clinician, Facility Admin, Staff, and Read Only.

Is every access logged?

Yes. Reads, creates, and updates are all recorded with who did it, what they touched, and the outcome, including denied attempts. Edits store before-and-after snapshots so a change can be traced. In production, platform logs are kept for 90 days in a central Log Analytics workspace.

How are Social Security numbers handled?

SSNs are masked to the last four digits (•••-••-1234) on every normal read. The full number is returned only through a dedicated reveal action, and each reveal is audited as its own event. Saving an edit never overwrites the real SSN with the masked value.

What happens if someone walks away from a screen?

The web app signs the user out automatically after 20 minutes of inactivity.

Does every user have multi-factor authentication?

Sign-in for Protocol users runs through Auth0, so MFA for clinicians and staff is configured there. Separately, MFA on the Azure accounts that can reach production is still an open checklist item.

Data protection

How stored and transmitted data is secured.

Is patient data encrypted?

1. At rest: all four storage accounts and Cosmos DB use Azure encryption with Microsoft-managed keys (verified in prod on 2026-09-16).
2. In transit: TLS 1.2 is the minimum everywhere, and HTTPS-only is enforced on the web app and all function apps.

Customer-managed keys are not configured. Whether to require them is a decision for your compliance officer, not a HIPAA blocker.

Is the database reachable from the internet?

The architecture uses private endpoints for Cosmos DB and all three function apps, and in production the function apps have public network access disabled. The web app is the public entry point.

Where are secrets like connection strings kept?

In Azure Key Vault, using managed identities with read-only access scoped per app. Database and storage connection strings and the search and AI keys have been moved. Auth0 secrets are still plain app settings and are on the to-do list. The vault also still allows public network access, which is flagged for hardening.

Can data be recovered if something goes wrong?

Yes. Production Cosmos DB uses continuous backup with point-in-time restore over a 7-day window. Key Vault has soft delete with 90-day retention.

How would we know about suspicious activity?

Microsoft Defender for Cosmos DB watches for anomalous access and possible exfiltration. Alerts email the protocol alerts mailbox for high Cosmos DB load and for failed-request spikes on each function app. Failed-login alerts (an Auth0 signal) and firewall-block alerts are not set up yet.

AI features

Encounter synopsis generation.

Does Protocol send patient data to an AI service?

Yes. The AI encounter synopsis sends structured encounter data, including mental status and risk fields, to a model in Azure AI Foundry. The Foundry account sits behind a private endpoint so traffic stays on the private network.

Is that covered by Microsoft’s BAA?

To confirm. Azure OpenAI and AI Foundry are a distinct service from Cosmos DB and Storage. Coverage under the Microsoft BAA must be confirmed explicitly, not assumed. Until then, treat the AI synopsis as needing sign-off before it processes real PHI.

Open items

What remains before going live with real PHI.

What still needs to be done?

Vendor and legal

1. Sign the Microsoft Azure BAA. Required before storing any PHI.
2. Sign a BAA with Auth0 (enterprise plans) and review its HIPAA settings.
3. Confirm AI Foundry is in scope of the Microsoft BAA.

Infrastructure

1. Deploy Front Door Premium with a WAF, then restrict the web app to it and add US geo-restriction.
2. Upgrade AI Search from Free and add a private endpoint.
3. Require MFA and just-in-time access (PIM) for Azure production accounts.
4. Penetration test once the WAF is live.

Application and process

1. Emergency access: no documented “break-glass” procedure yet.
2. Integrity: audit logs show tampering but do not prevent it (no immutable storage or signing).
3. Accounting of disclosures: the audit log covers internal access, not what was sent to outside parties.
4. Minimum necessary: roles gate access, but there is no field-level filtering, so Staff and Clinician reads return the same encounter shape.
5. Formal risk analysis, sanctions policy, workforce onboarding and offboarding procedures, and a written incident response plan.

Which of those are true blockers?

The BAAs, the formal risk analysis, and the emergency access procedure are required elements and should come first. Customer-managed encryption keys and the extra alert types are worth doing but are judgment calls.

Your role

HIPAA is shared: the platform does its part, and so does your organization.

What is our organization responsible for?

1. Assigning the right role and facility to each user, and removing access promptly when someone leaves.
2. Training staff and keeping a sanctions policy for misuse.
3. Reviewing audit logs and acting on anything unusual.
4. Keeping BAAs current with every vendor that touches PHI.

What should we do if we suspect a breach?

Report it immediately to your privacy or security officer and preserve the audit logs. HIPAA requires notifying affected individuals without unreasonable delay and no later than 60 days after discovery. A written incident response plan is still on the open list, so agree who owns each step before you need it.

Who makes the final compliance call?

Your designated compliance or privacy officer, ideally with legal counsel. This FAQ describes the technical state of the platform and is not legal advice.