The policy set the rule requires, what separates a usable policy from a template, and how to keep acknowledgement records that hold.
What the rule requires
Policies and procedures reasonably designed to comply with the standards, documented in writing, maintained for six years, reviewed periodically, and updated as needed.
That summary compresses two provisions: §164.316 for the Security Rule and §164.530 for the Privacy Rule. Note what the rule does not require — a specific number of documents, a specific format, or a specific naming convention. “Reasonably designed” is doing the work: a five-person telehealth startup and a hospital network are both compliant with very different policy sets, provided each set covers the applicable standards and describes reality. The flexibility cuts both ways, though. Because there is no prescribed template, the defence “we used the standard policies” does not exist. What exists is “our policies cover the standards and match our operations”, and only you can make that true.
A distinction worth keeping crisp because reviewers do: a policy states the rule (“access is granted on least privilege and reviewed quarterly”); a procedure states the steps (“manager submits request, Security Officer approves, IT provisions, ticket recorded”). Most findings against policy sets are actually missing procedures — the what without the how.
The minimum viable policy set
Roughly 20–30 documents covering security management, access control, workforce security, training, incident response, contingency planning, device and media, privacy practices, minimum necessary, patient rights, breach notification, and vendor management.
Mapped against the rule, the set clusters naturally. From the administrative safeguards: risk management, sanctions, workforce security (joiner–mover–leaver), access management, training, incident response, contingency planning, and evaluation. From the physical safeguards: facility security, workstation use, device and media disposal — plus remote work and BYOD policies for distributed teams. From the technical safeguards: access control, authentication and passwords, encryption, audit logging, transmission security. From the Privacy Rule: notice of privacy practices, minimum necessary, patient rights procedures, authorisations. Then breach notification and vendor management round out the set.
Resist the temptation to merge everything into one omnibus document. A single 90-page policy is technically permissible and operationally useless — nobody reads it, nobody owns sections of it, and updating one paragraph re-triggers acknowledgement of the whole. Twenty focused documents with named owners beat one monolith every time.
Template versus policy
A template describes a generic organisation. A policy describes yours. If your policy references a role you do not have or a system you do not run, it is evidence against you, not for you.
This is worth being blunt about because templated policy sets are the most common artefact we see in gap assessments. The tells are always the same: a “Chief Information Security Officer” at a twelve-person company, a visitor-badge procedure at a remote-only company, encryption standards for a database platform nobody runs. Individually these are cosmetic; collectively they tell an investigator that the policies were purchased, not implemented — and an unfollowed policy is worse than a missing one, because it documents a standard you set for yourself and then ignored.
Templates are still the right starting point — writing twenty policies from a blank page is a poor use of anyone’s month, and our free template library exists precisely for this. The discipline is in the adaptation: delete every clause describing a control you do not have, rename every role to one that exists, and read each procedure asking “did we actually do this last quarter?” If the answer is no, either start doing it or delete the claim.
Keeping the set alive
Policies decay at the speed of your organisation. Three habits keep the set current: give every policy an owner and a next-review date, and let the annual evaluation under §164.308(a)(8) audit the calendar. Trigger off-cycle reviews on material change — new system, new vendor category, office move, incident. And version properly: superseded versions archived read-only, effective dates on everything, because the six-year retention applies to history, not just the current text, and investigations ask what the policy said on the date of the incident.
Acknowledgement that holds up
Record the person, the policy, the version, and the timestamp. ‘Everyone signed the handbook in 2023’ is not an acknowledgement record.
Acknowledgement is where policy meets evidence. The record you want, per person: which document, which version, when acknowledged, collected through a mechanism that identifies the individual. Re-collect on material updates and at hire before access is granted. The handbook-signature approach fails on every axis — it cannot say which policies were included, which version, or whether the person hired since has ever seen them. And chase the gaps: an acknowledgement report showing 60% completion is not 60% of the evidence, it is documentation that 40% of your workforce never agreed to the rules you will cite when sanctioning them. Complete, current acknowledgement records are among the first things both OCR and enterprise customers ask for, and among the cheapest to get right with any tracking mechanism at all.
How reviewers read a policy set
It helps to know the reading order on the other side of the table, because it is not front-to-back. A reviewer — OCR investigator or enterprise security team alike — typically samples: pick three specifications, find the policy that implements each, then ask for the operational trace. Does the termination policy’s same-day revocation show up in an actual departure’s records? Does the log review policy’s monthly cadence show up as twelve dated entries? Does the sanction policy have even one application on file? The set passes or fails on the traces, not the prose.
They also read for internal consistency, which is where assembled-over-time policy sets quietly fail: the password policy that contradicts the access policy’s MFA claim, the incident plan naming a role the org chart retired, two documents claiming different review cadences for the same control. An annual consistency pass — one person reading the whole set in a sitting, flagging contradictions — is tedious and catches more findings than any tooling.
Finally, they read the dates. A set where every document says “reviewed 2026” on the same day in the same hand reads as a pre-audit scramble; a set with staggered, plausible review dates across the year reads as a living programme. You cannot fake the second pattern retroactively, which is precisely why it is persuasive — and why starting the review calendar now, however imperfectly, beats perfecting it later. A policy set that is 80% complete and demonstrably alive outperforms a complete set that is demonstrably embalmed, in every audience that matters.
Where SuperHIPAA fits
Everything above is work. The platform does the parts that are mechanical — evidence collection, acknowledgement tracking, register maintenance, renewal reminders — and our team does the parts that need judgement. You keep the parts that need to be yours.
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.