HIPAA’s Proposed Technology Asset Inventory and Network Map: A Data-Model Problem

The HIPAA Security Rule rewrite asks for a maintained inventory and network map of every system that touches ePHI. Most providers cannot produce one today, and the reason is not laziness. It is that they have been treating a data-model problem as a documentation exercise.

The Office for Civil Rights published its Notice of Proposed Rulemaking to strengthen the HIPAA Security Rule in the Federal Register on 6 January 2025, with the comment period closing on 7 March 2025. At the time of writing the final rule has not been issued, and the published timeframes have slipped. That is a reason to prepare, not to wait: the requirement most likely to expose the state of your estate is one of the least glamorous in the whole proposal — a written technology asset inventory and a network map showing how electronic protected health information moves through your systems, reviewed on an ongoing basis and at least once every twelve months, and updated whenever operations change.

What the proposal actually asks for

Strip away the commentary and the substance is narrow and specific. A regulated entity would have to maintain an inventory of the technology assets in its environment and a network map illustrating the movement of ePHI across and beyond that environment. Both would feed the written risk assessment as a foundational input rather than sit beside it as an appendix. The proposal also removes the long-standing distinction between “required” and “addressable” implementation specifications, so the inventory and map would apply across the board rather than being something a firm could reason its way out of.

None of that is radical as a security expectation. You cannot protect what you cannot enumerate, and the inventory-and-map pairing is the backbone of the broader overhaul that also brings mandatory encryption, multi-factor authentication and tighter asset controls into scope. The difficulty is not the concept. It is the word “maintain”.

Why a diagram is not an inventory

Most providers already have something they would offer if a supervisor asked. It is usually a network diagram drawn in Visio or Lucidchart by someone who has since left, accurate on the afternoon it was finished and drifting out of date within weeks. It shows boxes and arrows. It does not tell you which of those boxes stores ePHI, which business associate stands behind each external arrow, whether the agreement covering that associate is current, or which control is supposed to be protecting the flow between two systems. It is a picture, not a model.

The proposed rule expects an accurate, maintained artefact, and “maintained” is precisely what a hand-drawn diagram cannot be. Manual documentation decays because every change to the estate — a new SaaS subscription, a migrated database, a decommissioned server, a renewed vendor contract — is a change that has to be remembered and transcribed by a person. It never is, not consistently, not across a real healthcare organisation with hundreds of applications and a procurement function that does not route through IT. This is the same failure mode I have described elsewhere as a data-model problem wearing a compliance deadline’s clothes: the obligation looks like paperwork, but the only durable way to satisfy it is to hold the information as structured, queryable data.

The model underneath

Once you accept that the deliverable is a dataset rather than a drawing, the shape of the problem clarifies. You need entities for the assets themselves, for the flows of ePHI between them, for the business associates who touch those flows, for the agreements that govern those associates, and for the controls that are meant to protect each flow. The network map is then not a thing you draw; it is a view you render from the flow records. The inventory is not a spreadsheet you update; it is a query against the asset table. A workable minimum looks like this.

-- ePHI asset-and-dataflow inventory (minimum viable schema)
-- Every system touching ePHI, the flows between them, the
-- business associate behind each external flow, and the
-- control protecting it. The network map is a VIEW over data_flow.

CREATE TABLE asset (
    asset_id        TEXT PRIMARY KEY,
    name            TEXT NOT NULL,
    asset_type      TEXT NOT NULL,   -- server, saas, database, endpoint, appliance
    owner_team      TEXT NOT NULL,
    environment     TEXT NOT NULL,   -- prod, dr, test
    stores_ephi     BOOLEAN NOT NULL,
    discovered_by   TEXT NOT NULL,   -- cmdb, cspm, edr, manual
    last_seen       TIMESTAMP NOT NULL
);

CREATE TABLE business_associate (
    ba_id           TEXT PRIMARY KEY,
    legal_name      TEXT NOT NULL,
    baa_signed_on   DATE,
    baa_expires_on  DATE,            -- NULL flags a missing or evergreen agreement to review
    subcontractors  BOOLEAN NOT NULL
);

CREATE TABLE data_flow (
    flow_id         TEXT PRIMARY KEY,
    source_asset    TEXT NOT NULL REFERENCES asset(asset_id),
    dest_asset      TEXT REFERENCES asset(asset_id),        -- NULL when the destination is external
    dest_ba         TEXT REFERENCES business_associate(ba_id),
    ephi_categories TEXT NOT NULL,   -- e.g. 'demographics,diagnoses'
    transport       TEXT NOT NULL,   -- https, sftp, hl7-mllp, api
    encrypted       BOOLEAN NOT NULL,
    CHECK (dest_asset IS NOT NULL OR dest_ba IS NOT NULL)
);

CREATE TABLE control (
    control_id      TEXT PRIMARY KEY,
    name            TEXT NOT NULL,   -- e.g. 'MFA on remote access', 'at-rest encryption'
    control_type    TEXT NOT NULL
);

-- Which control protects which flow; the join a supervisor will ask you to run.
CREATE TABLE flow_control (
    flow_id         TEXT NOT NULL REFERENCES data_flow(flow_id),
    control_id      TEXT NOT NULL REFERENCES control(control_id),
    PRIMARY KEY (flow_id, control_id)
);

The point of modelling it this way is that the difficult questions become queries. Which ePHI flows to an external party have no signed BAA behind them? Which flows are unencrypted in transit? Which assets that store ePHI have not been seen by a discovery tool in thirty days? Those are single joins against this structure. Against a Visio file they are a week of someone’s time and a hopeful email chain.

Discovery is the part that keeps it honest

A schema does not populate itself, and this is where the twelve-month review clause bites. An inventory maintained by hand is accurate at the moment of the annual review and wrong by the following month. The only version that survives contact with a real estate is one fed from tooling that already watches the environment: the configuration management database, endpoint detection agents, cloud security posture management, identity and access logs, and network flow data. Each of those sees a slice of the truth. The discovered_by and last_seen fields exist so that the model records which source vouched for each asset and when, which turns “is this current” from a judgement call into a freshness check you can run daily.

The map, then, is generated. You render the topology from the flow records rather than maintaining a picture in parallel, so the picture cannot disagree with the data. When an asset stops being seen, when a BAA lapses, when a new unencrypted flow appears, the model shows it without anyone redrawing anything. That is the difference between an inventory and a diagram, and it is the difference the proposed rule is quietly built around.

What a supervisor will test

Enforcement of a maintained inventory does not look like reviewing a document. It looks like asking a question the document cannot answer on its own: show me every system that handled this patient’s record, show me the associate on the other end of that interface and the agreement covering it, show me when this asset was last verified as present. An organisation with a living model answers in minutes. An organisation with a diagram and a spreadsheet answers with a project. The same gap is already surfacing in cyber insurance underwriting, where carriers have started asking for asset and dependency evidence that firms assumed they had and discover they do not.

Treat the inventory and map as a schema to be populated from discovery, not a diagram to be redrawn each January, and the proposed requirement becomes an engineering task with a clear finish line. Treat it as documentation and you will pass the annual review and fail the first question a regulator or an incident actually asks. A point-in-time diagram is not an inventory, and the rule was written by people who know the difference.