A bring-your-own-device policy covering enrolment, containerisation, remote wipe, and the consent language you need from staff.
What is in the download
- Format: DOCX
- Length: 6 page(s) / file(s)
- Includes: rule citations, fill-in guidance in the margin, and a completed example
- Licence: free to modify and use commercially
What is in the template
Personal devices touching ePHI sit at the awkward intersection of the Security Rule’s device and media controls (§164.310(d)) and your workforce’s reasonable expectation that you do not own their phone. The template manages that tension in six sections: eligibility and enrolment — which roles may use personal devices for which purposes, and the MDM or mobile-application-management enrolment that gates access; minimum device requirements — supported OS versions, screen lock, device encryption, no jailbroken or rooted devices; containerisation — keeping organisational data in a managed profile or approved apps, so ePHI never lands in personal photo rolls, keyboards, or backup services; remote wipe — what the organisation can erase (the container, or the device, and under which circumstances), which is the clause that generates the most questions; the departure procedure — what happens to organisational data on personal devices at offboarding; and the consent form — a signed acknowledgement that the employee understands the monitoring and wipe capabilities, which protects both sides and is the piece most home-grown BYOD policies miss entirely.
How to use it
- Read it end to end before filling anything in.
- Delete every clause describing a control you do not have. An untrue policy is evidence against you.
- Assign an owner and a review date to each section.
- Publish it, collect acknowledgements against the version number, and retain both for six years.
Step two bites hardest here: if the policy says devices are enrolled in MDM and containerised, and half your clinicians read patient email in an unmanaged mail app, the policy is describing a control you do not have. Either deploy the tooling first or scope the policy to what is actually enforced.
How to customise it
The first decision is scope: which data and apps are permitted on personal devices at all. Many small organisations land on “email and messaging through managed apps, nothing else”, which keeps the policy short and enforceable. The second is the wipe boundary — container-only wipe is easier to get consent for and usually sufficient; full-device wipe needs explicit, prominent consent language. The third is stipends and expectations: if you require personal devices for work, decide whether you compensate, and reflect local employment law — this is a template, not legal advice. Fill in your actual MDM product, your supported OS floor (and who updates it as versions age), and the named contact for lost-device reports, then make the reporting expectation concrete: a lost device is a security incident under your incident response plan, reportable within hours, not at the next convenient stand-up.
Common mistakes
- A policy without tooling. BYOD rules enforced by hope are the classic paper control. If you cannot deploy at least managed apps, the honest policy is “no ePHI on personal devices” — which is also a valid answer.
- Ignoring the messaging reality. Clinicians will text about patients unless you give them an approved channel that is as fast as texting. The policy should name the channel, not just prohibit the alternative.
- No consent signature. Remote-wiping a device without documented consent is how a security control becomes an HR incident. The consent form is not optional ceremony.
- Forgetting departures. Offboarding checklists that revoke SSO but leave the mail profile on a personal phone leave ePHI walking out the door.
- Treating encryption as assumed. Modern phones encrypt by default, but the policy should still require it — the lost encrypted device is the one that stays an incident rather than becoming a reportable breach.
Related templates
BYOD is one panel of the distributed-work triptych: the remote work policy covers the environment the device is used in, and the access control and password policies govern the identities and credentials on it. The encryption policy sets the standards the device requirements reference, and the physical safeguards guide explains how personal devices fit the Security Rule’s device and media controls.
The honest limitation
A template is a starting point, not a program. It cannot record who acknowledged it, prove it was followed, or update itself when your environment changes. Those three things are what the platform does, and they are the difference between having documents and having compliance.
Start where you are
Take the free readiness assessment — 24 questions, about eight minutes, no call required. You get a scored report identifying which required specifications you are missing and what to fix first. If it turns out you are further along than you thought, we will tell you that too.