HIPAA vs GDPR device inventory: two laws, one register

A dental practice in London treating US expatriate patients. A telemedicine clinic in New York seeing Canadian and European visitors on business trips. A veterinary reference lab in Warsaw receiving samples from a partner practice in Boston. Every one of these operations sits at a compliance intersection where HIPAA and GDPR both apply — and the device inventory register is one of the concrete places the two regulations meet.

Most compliance articles pick one side. This one maps the actual regulatory text of HIPAA §164.310 directly to GDPR Articles 30 and 32, then shows how a single device register can satisfy both without doubling the work.

Two laws, one operational question

Both laws ask the same core question: which devices touch protected data, who has them, where do they live, and what happens to them when you retire them?

HIPAA calls the data electronic protected health information (ePHI) — 45 CFR §160.103. GDPR calls it personal data of a data subject relating to health — Article 4(15). Different labels, same core: patient data on a device.

Both laws require documented, maintained records of the devices that carry that data. HIPAA does it under §164.310(d)(2)(iii) (Accountability). GDPR does it under Articles 30 (records of processing activities) and 32 (security of processing).

HIPAA's requirement — §164.310(d)(2)(iii)

> "Maintain a record of the movements of hardware and electronic media and any person responsible therefore."

That is the device inventory. Combined with §164.310(d)(2)(i) (Disposal), §164.310(d)(2)(ii) (Media Re-use), and §164.310(d)(2)(iv) (Data Backup and Storage), it establishes:

Detail on the HIPAA side lives in the [HIPAA §164.310 pillar](/blog/hipaa-inventory-compliance).

GDPR's requirement — Articles 30 and 32

Article 30 — Records of processing activities

> "Each controller ... shall maintain a record of processing activities under its responsibility. That record shall contain all of the following information: (a) the name and contact details of the controller ...; (b) the purposes of the processing; (c) a description of the categories of data subjects and of the categories of personal data; (d) the categories of recipients; (e) transfers of personal data to a third country or international organisation ...; (f) the envisaged time limits for erasure of the different categories of data; (g) a general description of the technical and organisational security measures referred to in Article 32(1)."

Article 32 — Security of processing

> "Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk ..., the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: (a) the pseudonymisation and encryption of personal data; (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing."

Article 30(1)(g) — "general description of technical and organisational security measures" — is where the device inventory sits. Without a documented list of the devices where health data lives, you cannot describe the security measures for those devices.

Field-by-field mapping

Which register fields serve both laws?

| Field | HIPAA §164.310 | GDPR Art. 30 / 32 |

|---|---|---|

| Device ID | Required (accountability) | Required (Art. 30(1)(g)) |

| Device type | Required | Required |

| Health-data status (ePHI / personal data) | Required §164.310(d)(2)(iii) | Required Art. 30(1)(c) |

| Physical location | Required (movement record) | Required Art. 32(1)(b) |

| Responsible person | Required §164.310(d)(2)(iii) | Required Art. 30(1)(a) (via delegated responsibility) |

| Movement history | Required | Recommended for Art. 32(1)(d) evidence |

| Encryption status | Recommended (breach-notification safe harbor, §164.404) | Explicitly encouraged Art. 32(1)(a) |

| Disposal record | Required §164.310(d)(2)(i) | Required (Art. 5(1)(e) storage limitation + Art. 32) |

| Backup before movement | Required §164.310(d)(2)(iv) | Required Art. 32(1)(c) |

| Cross-border transfer note | Not required by HIPAA | Required if applicable Art. 30(1)(e) |

| Data-category description | Not required | Required Art. 30(1)(c) |

| Erasure-request handling | Not required (HIPAA has correction rights, not erasure) | Required Art. 17 |

Ten of twelve fields serve both laws. GDPR adds two on top: cross-border transfer notes and data-category description. A single register with all twelve columns satisfies both.

Where they diverge — the four gaps to know

1. Business Associate vs Data Processor

HIPAA §164.502(e) and §164.504(e) require a Business Associate Agreement whenever a vendor stores or processes ePHI. GDPR Article 28 requires a Data Processing Agreement whenever a processor handles personal data.

Different names, similar core: a written contract binding the vendor to the same data-protection standards as the practice. If you use a US vendor that handles data of EU citizens, you need both — the BAA for HIPAA and the DPA (often combined into one document with GDPR-specific annexes) for GDPR.

2. Breach thresholds

HIPAA §164.404 requires notification to affected individuals within 60 days of discovery. Breaches affecting 500 or more individuals require HHS notification immediately.

GDPR Article 33 requires notification to the supervisory authority within 72 hours. Article 34 requires notification to the data subject "without undue delay" only if the breach is likely to result in a high risk to the rights and freedoms of natural persons.

Both require a breach register — a documented log of every breach event with impact assessment. That register lives alongside the device register.

3. Rights of the individual

HIPAA gives patients the right to access records (§164.524) and to request corrections (§164.526). Nothing more.

GDPR gives data subjects a broader set: access (Art. 15), rectification (Art. 16), erasure — the right to be forgotten (Art. 17), restriction (Art. 18), portability (Art. 20), and objection (Art. 21).

For device inventory purposes, the erasure right is the operationally relevant one. When a data subject requests erasure, the device register tells you which devices held their data and where those devices are now — including in employee homes and vendor cloud environments.

4. Enforcement bodies and penalties

HIPAA: HHS Office for Civil Rights (OCR). Penalties tier from tens of thousands to millions of USD per violation category per year.

GDPR: national data protection authorities (ICO in the UK, CNIL in France, UODO in Poland, DSB in Austria, and equivalents across the EU/EEA). Penalties up to 4% of global annual turnover or €20 million, whichever is higher (Art. 83(5)).

Different regulators, similar practical outcome: the device register is one of the first things they ask for.

Sample entry that ticks both boxes

A dental operatory tablet at a London practice serving US expatriate patients:

- 2026-03-15 — received from Apple; provisioned by NorthStar IT

- 2026-03-16 — moved to Operatory 2

That single entry answers both §164.310 questions and Art. 30/32 questions in one look.

Multi-jurisdiction practice: one register, both laws

Practices that see patients from both jurisdictions do not need two registers. They need one register with a superset of fields — the twelve above — and clear policies describing how each field maps to the two frameworks.

Field-level guidance:

How [Asseto](/for/medical-clinics) fits both laws

Asseto's asset register is field-flexible. The twelve columns above become custom fields once, applied across the register. Movement history is a first-class concept — the audit trail satisfies §164.310(d)(2)(iii) and Art. 32(1)(d) simultaneously.

Vendor rows link to the device: if NorthStar IT services three tablets and two workstations, that vendor appears on all five device entries. BAA and DPA references live on the vendor row and are visible to auditors from either side of the Atlantic.

**Data-residency signal:** Asseto is EU-hosted on Supabase (eu-west-1). Every operation stays inside the EU by default. For GDPR that removes the cross-border-transfer complexity when using Asseto itself. For US practices using Asseto strictly for device metadata (no ePHI in notes fields), the register itself stays outside HIPAA's ambit and can be integrated with the rest of your compliance stack without dragging BAAs across it.

**What Asseto does not do — honestly:** breach-notification workflow, data subject request (DSR) handling, DPA lifecycle management. Those belong in a purpose-built privacy management platform (OneTrust, TrustArc, DataGrail) if you need them. Asseto is the device metadata layer — the one the OCR investigator and the DPA supervisor both ask about first.

Get the register right once

A device register that satisfies both laws is not twice as much work as one that satisfies either. It is roughly 15% more work than either alone — because the fields overlap so heavily. The overhead is worth it the first time a US patient becomes an EU resident (or vice versa) and you do not have to migrate a register.

Start today. Walk the practice with a clipboard. Every device that touches health data — write it down. Add the twelve columns. Assign the twelve values. In an afternoon a two-chair dental practice serving both markets has a register that survives an OCR audit and a Data Protection Authority inquiry.

[Try Asseto free](/signup) and stand up a HIPAA + GDPR device register in an afternoon. CSV import in five minutes. Twelve-column setup in twenty. Vendor agreements linked in ten. You keep the register. Both regulators cover your back. And the next inspection stops being the thing you dread — on either side of the Atlantic.