How do you map where ePHI lives for a HIPAA risk analysis?
The Security Rule requires the scope of your risk analysis to cover all electronic protected health information (ePHI) your organization creates, receives, maintains or transmits, in every form of electronic media, and you must document where that ePHI is stored, received, maintained or transmitted. If a risk analysis is overdue or a customer or regulator has asked for an inventory, start here, because every later step in the analysis depends on knowing which systems hold ePHI and how it moves between them. Your organization owns this inventory and the data flow map. An implementation partner can help collect the evidence, build the asset list and draw the diagrams, but the content must reflect your environment and be approved internally. No outside party issues a HIPAA certificate for this work, so a clean diagram is evidence for your own analysis, not a credential.
The scope varies with how your organization runs. The number of systems matters, but so does the way ePHI enters and leaves: intake through patient portals, faxes converted to electronic images, lab interfaces, claims clearinghouses, and reporting exports. Cloud use adds accounts, regions and managed services that may not appear in a traditional server list, and each business associate that stores or processes ePHI for you belongs on the map with its role identified. The hardest part is usually shadow tools, such as file sharing services, messaging apps, spreadsheets and personal devices that staff use to move patient data. Start with the business process, follow a sample of real records from intake to archive, and record every system the records touch. Confirm with your security official and system owners that the result matches what actually happens, not only what the architecture documents say.
Before you finish, record the hardware and electronic media movements that 45 CFR 164.310(d)(2)(iii) asks you to track, including who is responsible for each device, and assign an owner and review date to the inventory so it can be kept current as the environment changes.
How to build the ePHI inventory and data-flow map
This sequence turns a vague sense of where patient data lives into a documented inventory and data-flow map that the risk analysis can rely on. Each phase produces a named artifact, so gaps are visible before the risk analysis begins.
Set scope and name owners
Confirm which entities, facilities, business units and services are in scope, and define ePHI for your organization: all electronic protected health information the organization creates, receives, maintains or transmits. Assign an owner for each business process and system family, and a single coordinator who holds the working file. The output is a scope statement and an owner roster. You know this step is done when every in-scope process has a named owner who has accepted the responsibility in writing.
Discover ePHI across systems
Work through the environment in every form of electronic media: EHR and practice management platforms, databases, file shares, email, endpoints, mobile devices, removable media, backup repositories, logging stores and cloud tenants. Pull system lists from configuration management, identity and asset tools, and cloud consoles, then ask each owner which of those systems hold or touch ePHI. The output is a draft inventory of systems with a data classification and a note on the ePHI type each one holds. Reconcile the draft against the discovery sources so that no system is recorded only from memory.
Trace business processes and third parties
Walk through the workflows that generate or use patient information, such as intake, scheduling, billing, claims, lab orders, imaging exchange and patient messaging. Record every point where ePHI is created, received, maintained or transmitted, including paper-to-electronic conversions and manual re-keying. Add each external party that receives or hosts ePHI, including business associates, subcontractors, clearinghouses and software vendors, and check whether a business associate agreement is on file for each. The output is a process list linked to systems and third parties, with gaps marked for follow-up.
Draw data flows from entry to exit
For each process, draw how ePHI enters the organization, moves between systems, is stored or cached, and leaves through interfaces, portals, backups or disposal. Mark every network boundary, protocol and integration point, and note where data is encrypted in transit or at rest, where it is not, and where it is unknown. OCR's recent recommendations emphasize mapping how ePHI enters, flows through and leaves systems, so the diagrams should show all three. The output is a set of flow diagrams, one per major process, each with a legend and version date.
Validate with system owners
Walk each diagram and inventory entry with the system owner and a representative from operations or security. Ask them to confirm the data types, the interfaces, the hosting location, the administrators with access and the retention or backup path, and to correct anything the discovery missed. Record each correction and who approved it. The output is a validated set of records with sign-off notes. You know this step is done when no owner reports an unrecorded system, interface or data type during the walkthrough.
Record hardware and media movements
Document how hardware and electronic media that hold ePHI are received, moved, reused, repaired and disposed of, and name the person responsible at each stage, as 45 CFR 164.310(d)(2)(iii) calls for a record of these movements. Link each asset to its inventory entry so that devices, drives and backup media can be traced to a system and an owner. The output is a hardware and media movement log, with a sample of recent movements checked against the log. The check confirms that the log is complete enough to follow a device from acquisition to disposal.
Issue the inventory, maps and open questions
Assemble the final deliverables: the ePHI inventory, the data-flow diagrams, the third-party register and the hardware and media log, with a version number and an approval date. List every unresolved item as an open question with an owner and the evidence needed to close it, and pass the package to the risk analysis team. Keep the open questions visible, because they show the reviewer which parts of the map are provisional. The output is a signed baseline and an open-question register that the next review can close or update.
Where ePHI usually hides outside the EHR
The EHR is the system most teams inventory first, but ePHI tends to spread into messaging, backups, endpoints, file shares, SaaS tools and logs. Each location below has a different owner, so the inventory works only if each one is assigned to someone who can confirm what is stored there.
Email and messaging
Patient details travel through email threads, shared inboxes, chat tools and text messages, often as attachments or copied into free text. Check whether these channels are approved for ePHI, whether mail is encrypted in transit, and whether retention and deletion settings match your records policy. IT usually owns the platform, while the practice or department manager owns how staff use it.
Backups and archives
Backup sets and archived mailboxes copy ePHI long after the source record changes or is deleted. Confirm which backup jobs include clinical systems, where copies are kept, who can restore them, and how long they persist. Infrastructure or platform teams usually own the backup tooling, and the data owner should approve retention periods.
Endpoints and removable media
Laptops, desktops, mobile devices, USB drives and exported reports can hold local copies of ePHI that never appear in a system list. Ask which devices are issued or allowed to access ePHI, whether disks are encrypted, and how media is tracked when it moves or is retired. Endpoint management or device administrators usually own this record.
File shares and collaboration drives
Shared network folders, spreadsheets and cloud document libraries often hold reports, referral lists and scanned forms that were exported from clinical systems. Check which groups can read each share, whether access follows job role, and whether stale folders are still active. Document owners or the IT team that administers the file service usually hold this responsibility.
SaaS and billing tools
Billing, scheduling, survey, transcription and practice management tools frequently receive patient data through integrations or staff uploads. Confirm which vendors create, receive, maintain or transmit ePHI, whether each has a business associate agreement in place, and which integrations move data between systems. The business owner who signed the contract, with the privacy or compliance lead, usually holds the list.
Logs and analytics copies
Application logs, audit trails, monitoring dashboards and reporting warehouses can capture patient identifiers in messages, queries or exports. Check whether log fields are scrubbed, who can read the analytics store, and how long each copy is kept. Platform engineering and data teams usually own these stores, and the security team should review what they contain.
What recent OCR settlements recommend about data flows
OCR's recent enforcement points to one starting place: know where electronic protected health information enters your environment, moves through it and leaves it. When HHS announced the $1,500,000 civil money penalty against Warby Parker on February 20, 2025, it recommended that regulated entities identify where ePHI is located, including how it enters, flows through and leaves their systems. That recommendation reads as a precondition for the rest of the risk analysis. If a flow is missing from the map, the analysis cannot test the safeguards on it, and the risk management plan cannot reduce a risk nobody has written down. Start by tracing each inbound feed, internal hop and outbound transfer, including interfaces to vendors, clearinghouses and backup services.
The Ambry Genetics settlement announced September 17, 2026 follows the same logic and adds more specific recommendations. OCR's list in recent settlements includes periodic risk analysis and risk management built into business processes, audit controls with regular review of activity, encryption in transit and at rest when appropriate, and role-specific training. For a data-flow map, each flow should carry a named control owner, a logging point and a reviewer. Confirm with your security team whether the audit logs for each flow are reviewed on a schedule, and who receives the alerts. Confirm, too, whether staff who handle each flow have training tailored to their role, not only a general annual course.
Ransomware cases show what happens when the inventory is incomplete. The BST & Co. CPAs ransomware settlement of August 18, 2025 is a reminder that an attacker only needs one system no one tracked. Before the next risk analysis update, ask whether every location holding ePHI is on the map, including laptops, removable media, copies in SaaS tools, test or reporting databases, and backups. Each unlisted location is a place where the safeguards you documented may not apply. Record who is responsible for each location, because the hardware and media movement record that the Security Rule requires only works if someone is accountable for it.
Spreadsheet, CMDB or discovery tooling: which fits your environment
A small practice usually runs a handful of workstations, one or two servers or a hosted practice management system, a few mobile devices and a shared printer or imaging device. At this scale a well-maintained spreadsheet is often the most practical inventory, provided someone owns it and updates it when equipment is bought, replaced or disposed of. Discovery tooling may add little because the environment is small enough to list directly, but a basic device list still needs to record hardware, serial numbers, the person responsible and where each device sits.
- Hardware and media: Record each workstation, laptop, server, backup drive and removable media item, with the person responsible and any movement between locations or users.
- Hosted systems: List every cloud or vendor-hosted application that holds ePHI, along with the vendor's business associate agreement reference.
- Data flows: Enter by hand how patient information enters (scheduling, referrals, faxes, portals), where it is stored and how it leaves (claims, labs, email).
- Business owners: Name the staff member accountable for each system, since a spreadsheet cannot infer this.
- ePHI classification: Mark which assets hold or transmit ePHI, because a device list alone does not show it.
Before relying on any tool, confirm with the vendor whether it can export its data, whether it can be reviewed on a fixed schedule, and whether you can edit ownership and ePHI fields yourself.
A multi-site health system typically combines hospitals, clinics, imaging centers, shared service data centers and many vendor applications, often with local exceptions at each site. A configuration management database (CMDB) or an asset management platform becomes valuable here because a spreadsheet maintained by several facilities teams quickly diverges. A CMDB can hold a shared model of servers, applications, network segments and their relationships, which helps when one application spans several sites.
- Discovery scans: Network and endpoint discovery can surface devices that facilities teams did not register, including medical devices on segmented networks, where scanning must be planned carefully.
- Application relationships: A CMDB can record which servers, databases and interfaces support each clinical application, which feeds the network map.
- Data flows across interfaces: Interface engines, HL7 feeds and file transfers usually need manual documentation of source, destination, content and encryption.
- Ownership and ePHI tagging: Clinical, revenue cycle and research owners must be assigned by hand, and each system's ePHI status must be confirmed by the owner.
- Site and movement records: Record hardware transfers between sites and the person responsible, since the movement record is a separate requirement.
Confirm that the tool can handle medical and legacy devices without disrupting them, that it supports reconciliation between discovery results and the registered inventory, and that it can produce the snapshot a risk analysis reviewer will need.
A cloud-first business associate often runs most ePHI workloads in infrastructure accounts, managed databases, container platforms and SaaS tools that change frequently. Cloud provider APIs and infrastructure-as-code repositories can describe much of this environment automatically, which makes inventory tooling more useful here than in a small office. The inventory must still reflect ePHI flows that cross accounts, third-party tools and subcontractors, which code and cloud APIs rarely describe in business terms.
- Resource discovery: Cloud inventory tooling can list compute, storage, databases and network resources across accounts, including resources created outside the standard process.
- Infrastructure as code: Templates and configuration repositories can show intended architecture, but they may differ from what is running, so reconcile the two.
- Subcontractor and SaaS flows: Document which subcontractors and SaaS tools receive ePHI, under what agreement and by which transfer path, since these are not visible in cloud APIs.
- Data classification: Automated tagging can help identify storage that may hold ePHI, but owners must confirm the classification.
- Change triggers: Link inventory review to change management so that new accounts, services or integrations prompt an update.
Confirm whether the tool covers every account and region in use, how it treats ephemeral resources, and whether it can export the inventory in a form that an assessor can read without the vendor's console.
On-premises and air-gapped environments keep ePHI systems inside controlled facilities, sometimes with no outbound connection for cloud-based inventory services. Discovery tools can still run inside the network, but their results depend on what the network allows them to see, and some devices may need manual entry. Air-gapped enclaves often use removable media for transfers, which makes media accountability and data flow records especially important.
- Internal discovery: Scanners and agents deployed inside the enclave can capture hosts and software, but they must be approved, tested and managed as part of the environment.
- Offline and legacy systems: Devices that are isolated or cannot run agents need manual records, including physical location and the person responsible.
- Transfer records: Document each removable media or cross-domain transfer, the content, the sender and recipient, and the reason, because these movements are central to the hardware and media record.
- Network map: Diagram enclave boundaries, gateways and approved transfer paths by hand, since automated discovery may not show intent.
- Offline reconciliation: Schedule periodic physical verification against the registered list, recording the date and the person who performed it.
Confirm that any tool operates without external connectivity, that its database and exports remain inside the enclave, and that updates can be applied through your approved transfer process.
What the proposed rule would require for asset inventories and network maps
The January 2025 proposed Security Rule revision would make a written technology asset inventory and network map mandatory, refreshed at least every 12 months and whenever the environment changes. The proposal is not law as of October 2026, but the cards below show the elements to prepare now, since they are the same records a risk analysis already depends on.
Written technology asset inventory
The proposal would require a written inventory of every technology asset that touches ePHI, including hardware, software, cloud services and electronic media. Current law already requires a record of hardware and media movements under 164.310(d)(2)(iii), so start by checking whether that record covers servers, laptops, mobile devices, backup tapes and SaaS tenants. Confirm who owns each entry and how entries are retired when assets leave service.
Network map of ePHI paths
The proposed network map would show how systems connect, where ePHI enters, moves through and leaves the environment, and which segments and trust boundaries sit between them. Illustrative example: a clinic's scheduling system syncing to a billing vendor over an internet link would appear as a labeled path with its encryption and authentication noted. Check that the map shows third-party connections, not only the internal network.
Event-driven updates
Beyond the annual review, the proposal would require the inventory and map to be updated when the environment changes, such as a new EHR module, a cloud migration or a vendor swap. Without a defined change trigger, records drift between reviews. Ask who approves changes to systems that handle ePHI and whether change tickets feed the inventory automatically.
Link to the risk analysis
An accurate inventory and map are the scope of the risk analysis, so gaps in these records become gaps in the analysis itself. Assessors commonly ask whether every system in the map was evaluated for threats and vulnerabilities. Confirm that each inventory entry carries an owner, a data classification and a link to its most recent risk assessment.
Status and timing to confirm
The proposed rule was published on January 6, 2025 with comments due March 7, 2025. The Unified Agenda lists final action projected for July 2027, and the rule remains proposed as of October 2026. Confirm the current status in the Federal Register and reginfo.gov before setting a compliance date, and treat any final text as potentially different from the proposal.
Questions buyers ask about ePHI inventories and data flow maps
How long does it take to build an ePHI inventory and data flow map?
The duration depends on how many systems hold or move ePHI, how well those systems are documented, and how many people must confirm the details. No researched timeline applies to every organization, so ask any partner for a duration tied to a written list of systems and interviews. The main drivers are the number of applications and interfaces, whether cloud accounts and shadow tools are included, how many business associates receive ePHI, and whether network diagrams already exist. A small practice with a few systems will finish far faster than a health system with hundreds of interfaces. Ask for the work to be broken into discovery, validation with system owners and documentation, each with its own deliverable.
Can we build the ePHI inventory in-house?
Yes, a covered entity or business associate can build the inventory with its own staff, and HIPAA does not require an outside party to do it. The work needs people who know where ePHI is created, received, maintained and transmitted, including clinical systems, billing, email, file shares, backups, mobile devices and vendor connections. Many teams find that the hardest part is not listing systems but confirming how data enters, moves through and leaves each one. An outside implementation partner can prepare the inventory template, run discovery sessions and document flows, but the organization keeps ownership of the content and the risk analysis that depends on it.
What do we need from system owners and department leads?
System owners need to confirm what data each system holds, who administers it, where it is hosted, which interfaces and integrations connect to it, and which vendors can access it. Department leads need to describe real workflows, such as how a referral arrives, how a lab result is routed or how a claim is transmitted. Ask owners for access to configuration details, data dictionaries and existing interface specifications where they exist. Plan time for review cycles, because a flow diagram that a system owner has not validated is weak evidence. Record who approved each entry and the date, so the document can be traced when systems change.
Can a consultant certify our ePHI inventory as HIPAA compliant?
No. HHS does not recognize or endorse private HIPAA certifications, and no Security Rule standard requires an entity to certify compliance. A consultant can help prepare the inventory, flow maps and supporting evidence, and an independent assessor can test them, but neither can issue a HIPAA certificate that HHS will accept as proof of compliance. HHS has also stated that a private certification would not prevent it from later finding a violation. Be wary of any vendor that promises a HIPAA certification for an inventory. Ask instead what the deliverable is, who reviews it and how it feeds the organization's risk analysis.
How often should we update the ePHI inventory and data flow map?
HIPAA does not set a fixed interval for updating the inventory, but the organization must keep its risk analysis current, and the inventory is one of its inputs. Update the inventory whenever a system, interface, hosting location, vendor or data flow changes, and review it on a regular schedule even when nothing obvious has changed. The January 2025 proposed rule would require a written technology asset inventory and network map reviewed at least once every 12 months and when the environment changes, but that rule was not final as of October 2026, so confirm its status before writing it into policy. Keep prior versions so you can show what the environment looked like at each assessment.
What should we ask an implementation partner for in a written scope?
A written scope should name the systems in and out of scope, the ePHI data types covered, and the locations included, such as cloud accounts, data centers, endpoints and backups. Ask for the deliverables in writing: the inventory register, data flow diagrams, a network map, a hardware and media movement record approach, and a list of open questions for the organization. Confirm who interviews which owners, how many review rounds are included, how changes after handover are handled and what the partner will not do. The scope should state that the organization owns the content and the risk analysis, and that an independent assessor, not the partner, issues any audit report. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
Does the inventory alone satisfy the HIPAA risk analysis requirement?
No. The inventory and data flow map are inputs to the risk analysis under 45 CFR 164.308(a)(1)(ii)(A), which asks the organization to assess the potential risks and vulnerabilities to ePHI it creates, receives, maintains or transmits. The analysis still needs threat and vulnerability identification, a rating of likelihood and impact, and documented current controls. Use the inventory to make sure every location where ePHI exists is covered, then carry the same entries into the risk analysis and risk management plan.
How DeployOpen prepares your ePHI inventory and data-flow evidence
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the ePHI inventory and data-flow map follow the systems you actually run. We prepare the inventory, flow diagrams and hardware records that your risk analysis depends on, while your organization owns the risk analysis, its conclusions and the decisions made from them.
How we scope
- Agree a written, fixed scope listing the systems, business units, hosting locations and vendors to be mapped for ePHI.
- Confirm which ePHI creation, receipt, storage and transmission points fall inside the scope, including backups and removable media.
- Name the owner on your side who will validate each inventory entry and approve the final data-flow map before handover.
How we build
- Collect ePHI locations from system configurations, database schemas, interface definitions, integration logs and network records.
- Draw data-flow diagrams showing how ePHI enters, moves through and leaves each system, with trust boundaries marked.
- Record hardware and electronic media with asset identifiers, locations, custodians and movement history for accountability.
How we hand over
- Deliver the ePHI inventory, data-flow diagrams and hardware and media records as documented files your team can maintain.
- Provide a short walkthrough so your security official and system owners understand how each map was built and validated.
- Document open questions, unmapped systems and assumptions so your risk analysis team can close them and record decisions.
How we support
- Update the inventory and flow maps when systems change, using the change records agreed during scoping.
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement closes.
- Confirm with your counsel or compliance lead how your inventory will be used as evidence, since only your assessor can judge sufficiency.
Sources and further reading
- 45 CFR 164.308(a)(1)(ii)(A), risk analysis implementation specification ↗
- HHS OCR Guidance on Risk Analysis ↗
- NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule ↗
- 45 CFR 164.310(d)(2)(iii), device and media accountability ↗
- HIPAA Security Rule proposed rule, 90 FR 898 ↗
- HHS Resolution Agreements and Civil Money Penalties ↗
