The six-year rule, what must be in writing, and what ‘available to those responsible for implementation’ means in practice.
Where the requirement lives
The documentation standard sits at 45 CFR §164.316, and it is short enough to summarise in three verbs: write it, keep it, update it. Implement reasonable and appropriate policies and procedures in written form (electronic counts). Retain them, and any required action, activity, or assessment, for six years. Review and update them in response to environmental and operational changes. The Privacy Rule carries a parallel requirement at §164.530(j) covering its own artefacts — notices, authorisations, complaint records, sanction records.
The reason this unglamorous section matters more than its length suggests: under HIPAA, undocumented compliance is legally indistinguishable from non-compliance. If OCR asks whether you trained your workforce in 2024 and no record exists, the answer is functionally no — regardless of what actually happened. Documentation is not the paperwork around the programme; for enforcement purposes, it largely is the programme.
The six-year rule
Policies, procedures, and any action, activity, or assessment required to be documented must be retained for six years from creation or last effective date, whichever is later.
The “whichever is later” clause is the part teams miss. A policy adopted in 2018 and retired in 2024 must be kept until 2030 — six years from its last effective date, not its creation. In practice this means your retention obligation for any given document ends six years after you stop using it, so a living policy’s history effectively never expires while the policy lives. Two common confusions worth clearing: this is a HIPAA administrative-records rule, not a medical-records retention rule — clinical record retention is governed by state law and is often longer. And six years is a floor; litigation holds, state law, and payer contracts can all extend it.
What must be written
Policies and procedures, risk analysis, risk management decisions, sanctions applied, training records, BAAs, incident and breach determinations, contingency plan tests, and periodic evaluations.
A useful mental model: every time the rule says “implement”, it implies a policy; every time it says “periodic” or “review”, it implies a dated record. Expanding the list into the evidence a reviewer actually accepts — the risk analysis with its methodology, not just its conclusions; risk management decisions including the rationale for accepted risks; addressable-specification decisions, where choosing an alternative measure requires the written reasoning; sanction records showing the policy is applied, not just published; training records with dates, content versions, and completions; the BAA register with signed copies; incident logs including the four-factor determinations for incidents judged not to be breaches; contingency plan test results, especially restore tests; access reviews; and the annual evaluation under §164.308(a)(8). If your programme runs on the template library, each template maps to one of these obligations — the documentation requirement is the index behind the whole set.
Availability
Documentation must be available to the workforce members responsible for implementing the procedures. A policy locked in a legal share drive fails this.
This is the requirement that turns documentation from a compliance artefact into an operational one. The incident response plan must be findable by the on-call engineer at 2 a.m., not by the compliance officer during business hours. The test is simple: pick three procedures, pick the people who would execute them, and ask them to find the current version unaided. Where they look first is where the documents should live. Availability also interacts with acknowledgement — a workforce member cannot meaningfully acknowledge a policy they cannot access, so the distribution channel and the acknowledgement record should be the same system.
Version control
Retention means retaining superseded versions too. When an incident is investigated, the question is what your policy said on the date of the incident.
The minimal viable discipline: every document carries a version number, an effective date, an owner, and a change note; superseded versions are archived read-only, never overwritten; and acknowledgements are recorded against the version, not the title. The failure pattern is the shared drive with AccessPolicy_final_v2_NEW.docx, where the history exists only as filename archaeology and nobody can say what was in force last March. When an investigator asks for “the policy as of the incident date” — and that is exactly how they ask — the answer must be a retrieval, not a reconstruction.
A structure that survives audits
What works in practice is one canonical repository organised by obligation rather than by department: policies with version history, registers (risk, vendor, asset, incident), records (training, acknowledgements, access reviews, tests), and agreements. Each folder answers a predictable request. Pair it with a review calendar — every document has a next-review date, and the annual evaluation checks the calendar ran. Whether that repository is a well-disciplined drive or a platform matters less than whether the discipline holds when the person who built it leaves; that durability is, honestly, the strongest argument for tooling.
Questions teams actually ask
Does everything have to be on paper? No — electronic documentation satisfies the rule fully, and in practice electronic is stronger because timestamps, version history, and access controls come for free. What matters is durability and retrievability across the six years, which rules out documentation living in one person’s inbox or a chat thread.
Do meeting notes and emails count as documentation? They can serve as supporting evidence, but they are a weak substitute for deliberate records. “The access review is discussed at ops meetings” is harder to defend than a dated review record with findings, because a reviewer cannot tell diligence from coincidence in meeting minutes.
What about documents from before our current tooling? They are still inside the six-year window and still requestable. Migrate the history, or at minimum archive the old repository read-only with an index. Losing pre-migration records is a self-inflicted gap that surfaces exactly when an investigator asks about the year before the platform.
Who is allowed to update policies? Whoever your own documentation says — which is the point. A change-control note in each policy (who may amend, who approves, how changes are communicated) turns updates from informal edits into governed events, and it is a one-paragraph addition that reviewers consistently notice.
Is there such a thing as too much documentation? Yes, and it has a cost: aspirational policies you do not follow are evidence against you, and sprawling duplicate documents guarantee contradictions. The goal is the smallest set that covers the standards and matches reality — then kept relentlessly current. When in doubt, prefer one honest page with an owner and a date over five thorough pages nobody will maintain.
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.