Part 2 unsecured-PHI definition

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

Current rule checkpoint

Live 42 CFR 2.11 gives unsecured protected health information the meaning in 45 CFR 164.402: PHI that has not been rendered unusable, unreadable, or indecipherable to unauthorized persons through a technology or methodology specified by the Secretary's guidance. The status depends on the data, protection, implementation, and current guidance.

Classify the information and entity

Current 42 CFR 2.11 separately defines unsecured protected health information and unsecured record. Record whether the data is PHI, a Part 2 record, or both; the covered entity, business associate, program, lawful holder, custodian, format, system, and event.

Use the incorporated HIPAA meaning

Current 45 CFR 164.402 ties unsecured PHI to the Secretary-specified technology or methodology. Record encryption or destruction method, configuration, keys, media, data state, evidence, date, exceptions, and reviewer. A vendor's secure label provides no method proof.

Map each notification pathway

An event can require analysis under Part 2, HIPAA, state privacy or breach law, consumer-health law, contracts, payers, insurers, licensing rules, and other sources. Track definition, discovery, recipient, deadline, content, owner, decision, and evidence separately.

Identify the PHI and its state

Inventory the affected records, identifiers, formats, systems, devices, media, messages, attachments, logs, backups, exports, and paper where relevant. Determine whether the data are PHI, include Part 2 records, and were stored, transmitted, displayed, copied, or disposed of. Preserve versions and time periods.

Do not infer protection from a product label or assume every data set in a health system is PHI. Analyze the actual information and actor.

Verify the technology or methodology

Compare the implemented protection with the current technology or methodology specified by the Secretary. Record algorithm or method, configuration, key management, device and system state, transport, access, integrity, dates, owners, exceptions, and evidence. Qualified security and privacy reviewers should assess whether it rendered the information unusable, unreadable, or indecipherable to unauthorized people.

A password, screen lock, proprietary format, partial encryption, deleted pointer, or vendor assurance may not answer the definition without implementation facts.

Test the complete data path

Review source, application, database, endpoint, removable media, network, interface, cloud storage, logs, backups, support tools, screenshots, notifications, exports, archives, disposal, and recipient systems. Information can be secured in one layer and exposed in another. Verify decryption keys, plaintext caches, temporary files, and recovery copies.

Use documented tests appropriate to the system without unnecessarily exposing the PHI during verification.

Keep security status and breach analysis separate

Unsecured status does not alone establish that a breach occurred, and secured status does not mean no security incident occurred. Preserve acquisition, access, use, disclosure, recipient, viewing, mitigation, and other facts for the separate breach and notification analyses. Begin containment immediately.

Apply Part 2, HIPAA, state, contract, professional, and other duties with privacy and counsel. Do not stop investigation after one encryption finding.

Monitor and remediate

Inventory encryption and approved methods, keys, certificates, devices, storage, routes, backups, exceptions, owners, and review dates. Test deployments and configuration drift. Retire weak or unsupported technology through a governed plan and recheck vendors.

When PHI was unsecured, contain access, preserve evidence, rotate or revoke credentials and keys as appropriate, identify recipients and copies, correct configuration, assess reporting and notification, and test remediation. Audit exceptions, failures, lost assets, vendor events, and stale inventories.

Keep a protection matrix by data class and location showing approved method, implementation standard, key or media owner, last validation, monitoring, exception, expiration, and recovery test. Reconcile the matrix with asset, application, cloud, vendor, backup, and data-flow inventories. A retired server or forgotten export can remain part of the unsecured-PHI analysis after the primary system is fixed. During acquisitions and migrations, verify predecessor controls and historical copies rather than assuming the destination platform's encryption covers them.

Example

Fifteen affected datasets are classified. Twelve preserve PHI and Part 2 status, regulated roles, method evidence, key facts, media, event, notification routes, and reviewer; three rely on a platform badge. Classification completeness is 12 of 15 datasets.

Unsecured-PHI checklist

• identify the PHI, Part 2 content, format, system, device, route, and copies;
• compare implemented protection with current Secretary-specified technology or methodology;
• preserve configuration, key, date, ownership, exception, and test evidence;
• inspect plaintext across applications, endpoints, logs, backups, exports, and disposal;
• conduct breach and notification analysis separately while containing the incident; and
• monitor drift, vendors, exceptions, lost assets, remediation, and retesting.

Unsecured status is an evidence-based property of the actual information and protection. Security product names and policy statements do not prove it.