The US Multi-Regulator Data Map: Building the System-of-Record Inventory Every Regime Now Assumes

Five US regulators now expect you to produce, on demand, an accurate picture of your systems and your data. Not one of them will accept “we have a spreadsheet somewhere” as an answer.

The SEC’s cyber disclosure rules, HIPAA’s proposed Security Rule overhaul, NYDFS Part 500, California’s CCPA and the forthcoming CIRCIA reporting rule read like five separate compliance projects, each with its own owner, its own template and its own deadline. Underneath, they share one assumption none of them states in so many words: that you already hold an authoritative inventory of your assets, the data those assets carry, who owns them, and how data moves between them. Most firms do not. They hold several partial inventories, maintained by different teams for different regulators, that quietly disagree with each other.

The assumption none of them states outright

Read the obligations as engineering requirements rather than legal text and the common dependency is obvious.

• SEC. The rules adopted in July 2023 require, under Regulation S-K Item 106, disclosure of the processes used to assess and manage material cybersecurity risk, and under Form 8-K Item 1.05, disclosure of a material incident within four business days of the materiality determination. You cannot judge whether an incident is material without knowing which systems and which data it touched.
• HIPAA. The Office for Civil Rights’ Notice of Proposed Rulemaking of January 2025 would, if finalised, require a written technology asset inventory and a network map showing how ePHI moves through the environment, reviewed and updated at least every twelve months. It is a proposal, not yet law, but the direction is set.
• NYDFS Part 500. The asset inventory duty at section 500.13, whose final phase took effect on 1 November 2025, requires covered entities to maintain a written policy and a documented asset inventory that tracks, among other things, owner, location, classification and end-of-life.
• CCPA/CPRA. To answer a Californian consumer’s access, deletion or correction request within the statutory window, you have to know where that person’s data lives and every service provider it flows to. That is a data map by another name.
• CIRCIA. The 2022 Act, and CISA’s proposed rule published in April 2024, would require covered critical-infrastructure entities to report a covered cyber incident within 72 hours and a ransom payment within 24 hours. The final rule has slipped into 2026, but those clocks are statutory. You cannot start them, let alone stop them, without knowing what is in scope quickly.

Every one of these presupposes the same underlying artefact. None of them supplies it. That is the gap firms keep filling badly.

Why five spreadsheets is the wrong architecture

The natural response to five obligations is five lists. The security team builds the NYDFS inventory. The privacy team builds the CCPA data map. Someone in the healthcare unit starts the HIPAA network map. The SEC disclosure controls owner keeps a critical-systems register. Each is populated by hand, from a slightly different source, at a slightly different time, and each begins to drift the moment it is signed off.

The failure mode is predictable. The same database appears in three inventories with three different owners and two different classifications. A system decommissioned last quarter is still listed as production in one place and gone from another. When a supervisor puts two of these lists side by side and asks which is correct, there is no answer, because none of them is the source of truth — they are all copies of a source that was never built. I have written before about the moment a regulator asks where your data lives and the room goes quiet; multiplying the number of lists does not fill that silence, it just distributes the uncertainty.

The correction is architectural, not procedural. Treat the inventory as a system of record — one governed dataset of assets, data classes, owners, flows and dependencies — and treat every regulator-specific document as a view derived from it. A view cannot contradict the record it is generated from. Reconciliation stops being a quarterly exercise because there is only ever one set of facts to reconcile.

One model, many views

The core data model is smaller than the compliance sprawl suggests. You need assets, a data classification catalogue, the mapping between assets and the data classes they hold, and the flows between assets. Ownership, criticality, location and lifecycle hang off the asset. Regime tags hang off the data class so a single record can serve HIPAA, CCPA and NYDFS at once. From that base, each regulator’s document is a query.

-- Canonical system-of-record inventory (PostgreSQL)
-- One governed source of truth. Every regulator view below is a
-- projection of these tables, never a separately maintained copy.

CREATE TABLE asset (
    asset_id     text PRIMARY KEY,
    name         text NOT NULL,
    kind         text NOT NULL,        -- server, database, saas, endpoint, network_device
    environment  text NOT NULL,        -- prod, staging, dev
    location     text NOT NULL,        -- region / datacentre / cloud account
    owner        text NOT NULL,        -- accountable person or team
    criticality  text NOT NULL,        -- supports NYDFS 500.13 prioritisation
    lifecycle    text NOT NULL,        -- active, end_of_life, decommissioned
    last_seen    timestamptz NOT NULL  -- written by automated discovery, not by hand
);

CREATE TABLE data_class (
    class_id     text PRIMARY KEY,
    label        text NOT NULL,        -- ePHI, PII_CA_resident, PCI, material_nonpublic
    sensitivity  text NOT NULL,        -- public, internal, confidential, restricted
    regime_tags  text[] NOT NULL       -- {HIPAA}, {CCPA}, {SEC}, {NYDFS}
);

CREATE TABLE asset_data (
    asset_id     text REFERENCES asset(asset_id),
    class_id     text REFERENCES data_class(class_id),
    lawful_basis text,                 -- relied on by the CCPA / privacy view
    PRIMARY KEY (asset_id, class_id)
);

CREATE TABLE data_flow (
    flow_id        bigserial PRIMARY KEY,
    from_asset     text REFERENCES asset(asset_id),
    to_asset       text REFERENCES asset(asset_id),
    class_id       text REFERENCES data_class(class_id),
    crosses_border boolean NOT NULL DEFAULT false,
    third_party    boolean NOT NULL DEFAULT false  -- service provider or vendor hop
);

-- NYDFS 500.13: a prioritised written asset inventory with owner and end-of-life
CREATE VIEW v_nydfs_asset_inventory AS
SELECT asset_id, name, kind, owner, criticality, lifecycle, location, last_seen
FROM   asset
WHERE  environment = 'prod'
ORDER  BY criticality DESC;

-- HIPAA proposed network map: assets holding ePHI and the flows between them
CREATE VIEW v_hipaa_ephi_map AS
SELECT f.from_asset, f.to_asset, f.crosses_border, f.third_party
FROM   data_flow f
JOIN   data_class d ON d.class_id = f.class_id
WHERE  d.label = 'ePHI';

The two views do very different jobs from identical data. One produces the prioritised, owner-attributed asset list a NYDFS examiner expects; the other produces the ePHI edge list that becomes a HIPAA network map. Neither is maintained. Both are generated. Add a CCPA view keyed on personal-information classes and lawful basis, and an SEC critical-systems view keyed on criticality, and the same four tables answer all four regulators without a single duplicated row.

Keeping it current without heroics

A model is only as trustworthy as its freshness. The reason hand-maintained inventories fail is that they depend on people remembering to update them, and people do not. The governed record has to be fed by automated discovery: cloud provider asset APIs, your CMDB, cloud security posture tooling, and data-discovery scanners that find where classified data actually sits. Discovery writes last_seen; anything not seen within a threshold is flagged for review rather than silently trusted.

The point is not to automate classification wholesale — sensitivity and ownership still need human judgement — but to make drift visible as an alert instead of a discovery made during an examination. When a new asset appears that discovery cannot map to an owner or a data class, that is a governance event on the day it happens, not a finding twelve months later. Knowing precisely which data an asset holds is also what lets you reason about exposure at all, which is the same discipline behind understanding which of your data is already exposed to longer-horizon threats.

Who owns this, and where it usually breaks

This is not a security project or a privacy project. It is a shared platform that both consume, and it needs a single accountable owner with the authority to make the security team and the privacy team draw from the same well. Where it breaks is ownership: each function wants its own list because its own list is the one it trusts. The NYDFS asset inventory duty and the HIPAA proposed technology asset inventory and network map are, at the data-model level, the same problem asked twice; a firm subject to both that maintains two inventories has doubled its cost and halved its confidence.

The regulators are not going to converge their paperwork for you. Build the one inventory they all assume you already have, and let each of them read the view it wants — because the alternative is discovering, in front of an examiner, that your five sources of truth were four too many.