Media Re-use
The HIPAA media re-use requirement means you must remove electronic protected health information (ePHI) from any electronic media before you repurpose it internally or hand it to someone else for re-use. Put written, repeatable sanitization procedures in place, match the method to the media type, and keep proof (tickets, logs, certificates) that sanitization happened. (45 CFR Parts 160, 162, 164)
Key takeaways:
- You need documented procedures that ensure ePHI is removed before any device or storage media is re-used. (45 CFR Parts 160, 162, 164)
- Operational control hinges on an asset disposition workflow: classify, sanitize, verify, approve, then release for re-use.
- Evidence matters as much as the wipe: auditors look for traceable records tied to specific assets and custodians.
“Media re-use” sounds narrow, but in practice it covers a high-volume set of daily operational moves: reimaging laptops, redeploying desktops, rotating shared mobile devices, repurposing servers, returning leased copiers, reallocating external drives, and reassigning virtual storage. Anywhere ePHI could persist on electronic media, you need a controlled process that removes it before the media changes hands or purpose.
HIPAA’s Security Rule requires you to implement procedures that remove ePHI from electronic media before the media are made available for re-use. (45 CFR Parts 160, 162, 164) The operational challenge is consistency: IT, Security, Biomedical/Clinical Engineering, and third parties (e.g., managed service providers, copier lessors, e-waste recyclers) all touch devices, and “informal” redeployment is where data remnants slip through.
This page translates the media re-use requirement into an executable control: define what counts as media, standardize sanitization methods by media type, build a release gate so nothing is re-used without proof of sanitization, and retain evidence that stands up in an audit. You should be able to hand an examiner a policy, a workflow, and a small set of records that demonstrate repeatability.
Regulatory text
Requirement (verbatim): “Implement procedures for removal of electronic protected health information from electronic media before the media are made available for re-use.” (45 CFR Parts 160, 162, 164)
What the operator must do:
- Create and run documented procedures that ensure ePHI is removed from electronic media before that media is re-used. (45 CFR Parts 160, 162, 164)
- Treat this as a process control, not a one-time project. Devices and storage move constantly; your procedure must be repeatable, enforced, and evidenced.
Plain-English interpretation (what “media re-use” means)
If a device or storage medium might contain ePHI, you cannot redeploy it, repurpose it, return it, or hand it off for any kind of re-use until you have removed the ePHI. (45 CFR Parts 160, 162, 164) “Removal” is not a promise or an assumption; it is an action you can show happened.
Common examples that fall under “re-use”:
- Reassigning an employee laptop previously used to access or store ePHI
- Reimaging desktops used in clinical areas
- Redeploying tablets or phones used for rounding, secure messaging, or EHR access
- Repurposing shared devices (workstations on wheels, check-in kiosks)
- Returning leased copiers/MFPs with internal storage
- Reallocating external drives or removable media used for support or data transfer
Who it applies to
Entity scope: Covered Entities and Business Associates. (45 CFR Parts 160, 162, 164)
Operational scope (who must execute it):
- IT operations (endpoint management, server/storage, help desk)
- Security (policy, oversight, verification, exception handling)
- Clinical engineering / biomedical teams (device servicing and redeployment)
- Facilities and procurement (returns, leases, surplus, e-waste workflows)
- Any third party that handles your equipment for repair, refurbishment, resale, recycling, or redeployment (treat as third-party risk, even when they “only pick up hardware”)
What you actually need to do (step-by-step)
1) Define “electronic media” for your environment
Create a scope statement that includes, at minimum:
- Endpoints: laptops, desktops, thin clients, tablets, mobile devices
- Storage: HDD/SSD, external drives, USB, memory cards
- Infrastructure: servers, SAN/NAS allocations being repurposed
- Embedded storage: copiers/MFPs, some medical devices, badge readers, kiosks
Add an explicit callout: if the asset stored ePHI or had local caching that could contain ePHI, it is in scope for sanitization before re-use. (45 CFR Parts 160, 162, 164)
2) Standardize sanitization methods by media type
Your procedure should map media type → approved sanitization method → verification step. Keep it simple enough that techs follow it.
A practical approach:
- Managed endpoints (corporate images): full wipe/reimage using your endpoint management standard, with encryption keys handled appropriately.
- Mobile devices: factory reset plus mobile device management (MDM) re-enrollment requirements; confirm encryption and remote wipe status before release.
- External/removable media: sanitize using an approved secure erase method or physically destroy when sanitization cannot be reliably validated.
- Copiers/MFPs: sanitize internal storage before return; if you cannot validate sanitization, require drive removal/destruction or contract terms that specify sanitization responsibilities and evidence.
Do not rely on “delete” or “format” language in a procedure without a defined secure method and a verification step. Your procedure must remove ePHI before re-use. (45 CFR Parts 160, 162, 164)
3) Build a “release gate” so nothing gets re-used without proof
Operationally, this is the make-or-break move.
Implement a gate in your ticketing/asset process:
- Asset is tagged “Pending Sanitization” when it is decommissioned, swapped, repaired, or prepared for redeployment.
- Only designated roles can mark “Sanitized” after they complete the procedure and attach evidence.
- Inventory/asset management status must prevent assignment to a new user or shipment to a third party until “Sanitized” is recorded.
If you run a mixed environment (IT, biomed, facilities), make the gate cross-functional. Otherwise devices bypass IT and reappear in service without the wipe record.
4) Add verification and exception handling
Verification can be lightweight but must be real:
- Confirm wipe task completion logs, management console status, or wipe reports tied to the device identifier.
- For higher-risk media (unknown state, damaged drives), require physical destruction or a documented exception with compensating controls.
Create an exception path for cases like:
- Device failure prevents sanitization
- Legal hold
- Device is stolen or cannot be recovered (this becomes incident analysis, not re-use)
5) Control third-party touchpoints
Media re-use commonly breaks at the boundary with third parties:
- Repair depots
- Copier lessors
- E-waste recyclers/refurbishers
- Cloud/colocation providers handling drive replacements
Minimum operational requirements:
- Contract language that assigns sanitization responsibility and requires evidence before re-use
- Chain-of-custody records for pickups/returns
- A receiving check that validates the asset is marked sanitized before shipment, or that the third party provides a certificate that matches your asset IDs
Daydream can help here by centralizing third-party due diligence artifacts (contracts, certificates of destruction, audit letters) and tying them back to the control owner and asset workflow, so you can answer “show me proof” without chasing emails.
Required evidence and artifacts to retain
Auditors typically want proof at three layers: policy, process, and execution.
Policy and procedure artifacts
- Media Re-use / Media Sanitization policy and SOP aligned to “remove ePHI before re-use.” (45 CFR Parts 160, 162, 164)
- RACI or role definitions (who can sanitize, who can approve release)
- Approved sanitization method matrix by media type
Operational execution evidence
- Asset inventory records showing device identifiers, status changes, and reassignment history
- Tickets/work orders for decommission, wipe, redeploy, return-to-lessor, or disposal
- Wipe logs/reports from endpoint tools or sanitization utilities, linked to asset ID/serial
- Chain-of-custody forms for assets transferred to/from third parties
- Certificates of sanitization/destruction where applicable, with matching identifiers
Oversight evidence
- Periodic sampling/QA checks that the procedure is followed
- Exception register with approvals and remediation notes
Common exam/audit questions and hangups
Expect these, and pre-build your answers:
- “Show me the procedure.” They want a written SOP that matches the regulatory text. (45 CFR Parts 160, 162, 164)
- “How do you know devices are wiped before reassignment?” They look for the release gate and inventory controls.
- “What about copiers, scanners, medical devices?” If your scope omits embedded storage, you will get stuck.
- “What happens when a drive is broken?” They want a documented exception path that still prevents re-use with ePHI.
- “How do third parties handle this?” They want contracts, chain-of-custody, and proof artifacts, not verbal assurances.
Frequent implementation mistakes (and how to avoid them)
- Mistake: Treating re-use as “IT only.” Fix: include biomed, facilities, and procurement in the workflow and approval gate.
- Mistake: No linkage between wipe evidence and asset identity. Fix: require serial/asset tag in tickets and wipe logs; reject evidence without identifiers.
- Mistake: Allowing “help desk quick swaps” without a ticket. Fix: enforce a ticket requirement for any reassignment; automate where possible.
- Mistake: Ignoring leased devices and copiers. Fix: add lease return checklists and contract requirements for sanitization evidence.
- Mistake: Assuming encryption alone solves re-use. Fix: keep encryption as a control, but still execute a documented removal procedure prior to re-use. (45 CFR Parts 160, 162, 164)
Enforcement context and risk implications
No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement context carefully and stick to operational risk. The risk is straightforward: residual ePHI on re-used media can lead to unauthorized disclosure, breach response obligations, and reputational damage. The control is a classic “preventable incident” area because failures often come from informal redeployment and weak chain-of-custody.
Practical 30/60/90-day execution plan
First 30 days (stabilize and stop gaps)
- Name a control owner (often IT Ops with Security oversight) and publish a short SOP that directly matches the requirement language. (45 CFR Parts 160, 162, 164)
- Inventory the re-use pathways: redeploy, repair, return, recycle, donate, storage reallocation.
- Implement an interim release gate: no reassignment or shipment without a ticket and a “sanitized” status.
- Identify high-risk media types you currently cannot sanitize reliably; route them to controlled destruction until the method is defined.
By 60 days (standardize and prove it)
- Publish the sanitization method matrix by media type and embed it in runbooks.
- Integrate asset status controls with ticketing so “pending sanitization” blocks reassignment.
- Add third-party requirements: chain-of-custody forms and required evidence (certificates, logs) for any third party handling media.
- Start QA sampling: check a subset of re-used assets for complete evidence trails.
By 90 days (operationalize and harden)
- Expand scope to embedded storage you missed early (copiers/MFPs, kiosks, specialty devices).
- Add exception management with approvals, tracking, and remediation actions.
- Train all relevant teams (IT, biomed, facilities, procurement) and publish a one-page checklist.
- Run an internal audit-style test: pick several re-used assets and demonstrate the full trail from decommission to sanitization evidence to reassignment.
Frequently Asked Questions
Does “media re-use” apply if the device never stored ePHI locally and only accessed the EHR via a browser?
Treat it as in scope if ePHI could be cached locally (downloads, browser cache, client apps, offline modes). Your procedure should define how you decide and document “no local storage” cases. (45 CFR Parts 160, 162, 164)
Are factory resets enough for phones and tablets?
A factory reset is a common baseline, but your procedure should also require verification (MDM status, encryption posture, successful wipe record) before the device is released for re-use. The key is proof that ePHI was removed before re-use. (45 CFR Parts 160, 162, 164)
What do we do with broken drives that can’t be wiped?
Your procedure should route non-sanitizable media to controlled destruction and document the exception and chain-of-custody. Do not allow re-use when you cannot remove ePHI. (45 CFR Parts 160, 162, 164)
How should we handle leased copiers and MFPs?
Add a return checklist and require documented sanitization of internal storage before the device leaves your control, or contractually require the lessor to provide evidence tied to your device identifiers. Treat the lessor as a third party in your due diligence process.
Do we need certificates of destruction for everything?
Not for everything. Keep whatever evidence your procedure defines as proof for that media type (wipe logs, tickets, management console reports). Use certificates for cases where destruction is the chosen method or where third-party handling requires formal proof.
How can a GRC team operationalize this without owning IT tools?
Own the control design: define the procedure, the release gate, and required evidence; then test a sample of re-use events for traceability. Tools like Daydream help by keeping third-party artifacts, chain-of-custody records, and control testing evidence in one place.
Frequently Asked Questions
Does “media re-use” apply if the device never stored ePHI locally and only accessed the EHR via a browser?
Treat it as in scope if ePHI could be cached locally (downloads, browser cache, client apps, offline modes). Your procedure should define how you decide and document “no local storage” cases. (45 CFR Parts 160, 162, 164)
Are factory resets enough for phones and tablets?
A factory reset is a common baseline, but your procedure should also require verification (MDM status, encryption posture, successful wipe record) before the device is released for re-use. The key is proof that ePHI was removed before re-use. (45 CFR Parts 160, 162, 164)
What do we do with broken drives that can’t be wiped?
Your procedure should route non-sanitizable media to controlled destruction and document the exception and chain-of-custody. Do not allow re-use when you cannot remove ePHI. (45 CFR Parts 160, 162, 164)
How should we handle leased copiers and MFPs?
Add a return checklist and require documented sanitization of internal storage before the device leaves your control, or contractually require the lessor to provide evidence tied to your device identifiers. Treat the lessor as a third party in your due diligence process.
Do we need certificates of destruction for everything?
Not for everything. Keep whatever evidence your procedure defines as proof for that media type (wipe logs, tickets, management console reports). Use certificates for cases where destruction is the chosen method or where third-party handling requires formal proof.
How can a GRC team operationalize this without owning IT tools?
Own the control design: define the procedure, the release gate, and required evidence; then test a sample of re-use events for traceability. Tools like Daydream help by keeping third-party artifacts, chain-of-custody records, and control testing evidence in one place.
Authoritative Sources
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream