GraphWarden and HIPAA: how the proxy supports your compliance obligations
The HIPAA Security Rule imposes administrative, physical, and technical safeguards on covered entities and business associates handling electronic protected health information (ePHI) inside Microsoft 365 and the Graph API. GraphWarden helps address the Technical Safeguards of 45 CFR §164.312 by centralizing access control to Microsoft Graph, producing a verifiable audit trail, and keeping Graph credentials inside your own Azure Key Vault. This document maps each §164.312 standard to GraphWarden's capabilities, with explicit limits on the parts of HIPAA that remain your responsibility.
Who this document is for
HIPAA context
HIPAA — the Health Insurance Portability and Accountability Act of 1996 — is enforced in the United States by the Office for Civil Rights (OCR) of the Department of Health and Human Services. The Security Rule at 45 CFR Part 164 Subpart C imposes three safeguard categories on covered entities and business associates handling electronic protected health information: administrative safeguards (§164.308), physical safeguards (§164.310), and technical safeguards (§164.312).
The Technical Safeguards in §164.312 cover access control, audit controls, integrity, person-or-entity authentication, and transmission security. The HITECH Act of 2009 strengthened these obligations with a federal breach notification framework (§164.404 to §164.414) and increased civil monetary penalties up to 2 million dollars per violation category per year. Business associates are directly liable under HITECH, which means every integration between your Microsoft 365 tenant and a third-party application that touches ePHI falls under a Business Associate Agreement (BAA) regime. GraphWarden addresses the technical surface of that integration.
HIPAA mapping to GraphWarden capabilities
| HIPAA section | GraphWarden capability | Status | Technical proof |
|---|---|---|---|
| §164.312(a)(1) Access Control | Graph endpoint allowlist via ruleset | Aligned | Ruleset YAML documents exactly which Graph endpoints each App Identity may reach. Unauthorized calls return 403. |
| §164.312(a)(2)(i) Unique User Identification | App Identity = unique principal per system | Aligned | Each integrated application has a dedicated App Identity; proxy audit logs record which identity made each call. |
| §164.312(b) Audit Controls | HMAC-authenticated audit endpoint | Aligned | Every proxied Graph call emits an audit event with timestamp, identity, path, status, latency. |
| §164.312(c)(1) Integrity | Response Filter transforms do not modify PHI in transit except where explicitly configured | Supported | Any field-level transformation is declared in the ruleset and auditable. |
| §164.312(d) Person or Entity Authentication | OAuth2 client_credentials against Graph, proxy client credentials to the app | Aligned | Two-layer credential model; the app never sees real Graph credentials. |
| §164.312(e)(1) Transmission Security | TLS 1.2+ end-to-end | Supported | Proxy enforces TLS for inbound and outbound; internal paths go over encrypted channels. |
Concrete scenario
A US regional hospital network runs a Microsoft 365 tenant and integrates a third-party telehealth SaaS. Without GraphWarden, the telehealth vendor holds the Graph credentials and can query every endpoint its Azure AD registration permits, including directory-wide user queries that extend beyond the clinical staff it serves. With GraphWarden, the telehealth App Identity has a ruleset restricting it to the Clinical-Staff security group and to the id, displayName, mail, and jobTitle fields. During an OCR investigation on §164.312(b) Audit Controls, the hospital produces the YAML ruleset (access-control artifact) and the audit log for the investigation window (identity, timestamp, endpoint, status), satisfying the audit-controls standard for the Graph surface.
Hosting and data residency
Hosted tier: the proxy runtime is in Azure Canada Central; the control plane runs in Canada East (OVHCloud). On-premise tier (Windows Service or Docker) inside your own infrastructure: no ePHI transits through a third-party GraphWarden infrastructure. Graph credentials (client secrets, certificates) never leave your Azure Key Vault: GraphWarden holds only their SHA-256 fingerprint to authenticate calls from your applications.
Cross-border PHI caveat. GraphWarden's Hosted tier is in Canada, NOT the United States. Cross-border PHI transfer from a US covered entity to a Canadian-hosted service has Business Associate Agreement (BAA) and data-transfer implications that are the customer's legal analysis — GraphWarden does not sign HIPAA BAAs for cross-border hosting. The On-premise tier keeps data in your jurisdiction and is the recommended posture for US covered entities that cannot move ePHI outside the United States.
Limits
GraphWarden helps address the Technical Safeguards of §164.312 but does not cover the entire HIPAA regime. The following items remain your responsibility.
- GraphWarden does NOT store or process PHI at rest — GraphWarden is a proxy, not a data store; PHI remains in Microsoft 365 and in your integrated applications.
- GraphWarden does NOT replace your Business Associate Agreement obligations — the BAA between your organization and each application vendor (and between you and your GraphWarden deployment contract, if hosted) is yours to negotiate and maintain.
- GraphWarden does NOT file breach notifications under §164.404 — the audit log scopes the incident, but the notification to affected individuals, to HHS, and to the media where applicable remains your responsibility.
- GraphWarden does NOT perform the risk analysis mandated by §164.308(a)(1)(ii)(A) — the proxy provides artifacts (rulesets, audit evidence) that feed the analysis, but the analysis itself remains your responsibility.
- GraphWarden does NOT cover the administrative safeguards of §164.308, including workforce training (§164.308(a)(5)) and sanction policy — these are administrative, not technical.
- GraphWarden does NOT cover the physical safeguards of §164.310 — facility access controls, workstation use, and device controls remain the deploying organization's responsibility.
Prepare your HIPAA brief with an AI assistant
Prepare a HIPAA compliance brief
Prepare a HIPAA compliance brief for my M365 tenant using GraphWarden, with focus on §164.312 Technical Safeguards.
I need to deliver to my HIPAA Security Officer:
1. Which §164.312 standards GraphWarden helps meet (section-by-section mapping)
2. Which HIPAA obligations remain under my responsibility (out of scope — BAA, breach notification, risk analysis, workforce training)
3. The technical artifacts to attach to my documentation package (YAML rulesets, audit log exports)
Reference documentation: https://graphwarden.com/llms.txt
Ask me:
- Whether I am a covered entity, a business associate, or both
- How many Graph-integrated applications touch ePHI today
- Whether my risk analysis is current and which retention tier my audit log uses
Reference: llms.txt
Troubleshooting
- An OCR auditor asks me to prove access control under §164.312(a)(1). Produce the relevant YAML ruleset and the audit log for the requested window through the HMAC
/auditendpoint; see Agent API. - My audit log does not show every Graph operation. Verify that the application actually routes through the proxy (check the
baseUrloverride). A call that bypasses the proxy is not logged — see App Identities. - My BAA with a vendor requires field-level minimization on a Graph query. Configure a Response Filter on the App Identity's ruleset to restrict returned fields; see Rulesets and Rules.
- How do I scope a breach notification window? Filter the HMAC audit export by App Identity and timestamp range for the incident period; the export satisfies the evidentiary part of the §164.404 workflow.
- Do I still need a BAA with GraphWarden? GraphWarden does not sign HIPAA BAAs for cross-border hosting — the Hosted tier is in Canada, and the legal analysis for PHI transfers from a US covered entity to a Canadian-hosted service remains your responsibility. On-premise deployments inside your infrastructure do not introduce a new BA relationship because no ePHI transits to a third-party processor — this is the recommended posture for US covered entities.
Resources
- For deployment, see On-Premise Windows Installation.
- For app identities, see App Identities.
- For the proxy trust model, see Trust Model.
- Data Processing Agreement (DPA) template — coming in a later phase .
Next steps
For a demo tailored to your HIPAA deployment, contact the GraphWarden team. Review the use cases to see how other US healthcare organizations have aligned rulesets to their §164.312 documentation. Bring to the session: your covered-entity or business-associate posture, your list of Graph-integrated applications that touch ePHI, your risk-analysis cycle, and the desired audit retention tier (90 days, 1 year, or 7 years).
Last reviewed: