164.316(b)(2)(i) Time limit: requirements and evidence

What HIPAA six-year documentation retention requires in practice

Keep every Security Rule policy, procedure and required record for six years from the date it was created or the date it last was in effect, whichever is later. That is the required implementation specification in 45 CFR 164.316(b)(2)(i), and it applies to the documentation your organization owns as a covered entity or business associate, not only to the final version of a policy. The clock does not restart when a document is superseded, so a 2019 policy that stayed in effect until 2023 is retained until six years after 2023, not after 2019. The retention duty covers two kinds of material: the written policies and procedures that describe how each Security Rule requirement is met, and the records of every action, activity or assessment the rule says to document, such as risk analyses, access reviews, training attendance, incident reports and contingency test results. Electronic storage is acceptable, but the records must be retrievable in full for the whole period. Ask your compliance lead to produce a retention schedule that lists each record type, its owner, its system of record and the date after which it may be disposed of. Versioned, dated records make this harder to prove than it sounds. A wiki or document system may keep every revision, but the retention clock depends on which version was in effect and when it was replaced, so the version history itself must survive any migration or tool retirement. Confirm that your platform keeps timestamps and authorship, that backups include the history, and that deletion or purge rights are limited to a documented process. Your records should let an auditor reconstruct what was in effect on any given date within the last six years.

Which documents and records fall under the six-year clock

Section 164.316(b)(2)(i) applies to documentation of every Security Rule requirement, not only the policy binder. The cards below sort the common document and record types into the clock, and note where covered entities and business associates each carry the duty.

Written policies and procedures

Every policy and procedure written to meet a Security Rule standard falls under the six-year clock, including access control, workstation use, sanctions and device disposal. Keep each version, not only the current one, because the period runs from when a version was created or last in effect. A policy replaced in a later year still needs its earlier version kept for six years from the date it stopped being in effect. Ask your team to confirm how superseded versions are archived.

Risk analysis and risk management outputs

The risk analysis itself, the risk management plan, and the list of identified threats and vulnerabilities are records of required assessments. Each update to the analysis is a new dated document with its own six-year period. Keep the decisions on which addressable specifications were adopted, rejected or replaced by an equivalent measure, along with the reasoning, because that reasoning is part of the record an assessor will ask for.

Training and awareness logs

Attendance records, training materials, and the dates of each workforce training session are records of an action the rule requires. Retain them with the version of the training content that was delivered, so you can show what each workforce member was taught and when. Records for a former employee should stay within the same six-year window measured from the date each record was created.

Security incident and response records

Incident tickets, investigation notes, containment steps, and post-incident reviews document the response procedures in action. Keep the record of the incident together with the response plan version that was in effect at the time. Breach assessments and any notification records should be retained under the same logic, since they show how the entity applied its procedures to a real event.

Access reviews and contingency test results

Periodic access reviews, the approvals that accompany them, and the results of contingency plan tests and data backup restoration exercises all show that required activities took place. Each review or test result is dated and becomes a record with its own six-year clock. Keep the scope and findings of each test so you can show what was tested, not just that a test occurred.

Business associate records held by the entity

Covered entities keep business associate contracts and the arrangements that document satisfactory assurances, and business associates keep their own subcontractor agreements and documentation of their safeguards. Both parties carry the duty for the records they hold. Confirm with counsel which contract versions must be kept, and whether a signed copy alone meets your own recordkeeping for each arrangement.

How an assessor tests six-year retention

This table sets out what an assessor does to test 164.316(b)(2)(i), the evidence they request, and the findings that most often cause problems. Read each row as a step in the test, and use the last column to check your own documentation before an assessment begins. The main takeaway is that retention is proven by dates and surviving versions, not by what the current file looks like.

Test step	What the assessor requests or checks	Common finding
Request the documentation inventory	A list of every Security Rule policy, procedure and required record, with creation date, last effective date and current status	No inventory exists, so the entity cannot show which documents fall under the six-year period
Sample documents across the rule	A selection of policies and records drawn from administrative, physical, technical and organizational requirements, not only the most recent ones	Samples reveal documents that were replaced without any trace of the earlier version
Check creation and effective dates	Metadata or approval records that show when each document was created and when it took effect	Retention is calculated from the file save date, which resets on every edit and understates the true period
Confirm superseded versions still exist	Prior versions retained for six years after each one was last in effect, with a way to retrieve them	Older versions were overwritten, deleted or lost during a platform migration
Review version history and change records	Version logs showing what changed, when and by whom, linked to the approval that authorized the change	Edits were made without a version record, so the assessor cannot reconstruct what was in effect on a given date
Test retrieval of a past version	A named older policy retrieved within a reasonable time, with its effective period shown	The entity can describe its past policies but cannot produce the documents themselves
Check retention for records of actions	Records of required reviews, risk analyses and training, kept for the same six-year period as the documents they support	Activity logs or review sign-offs are purged on a shorter schedule than the policies they support
Verify retention settings and backups	Written retention rules, backup configuration and evidence that deletion jobs do not remove documents still inside the period	Automated cleanup or backup rotation deletes documentation before six years have passed

How to set up retention that holds up to an audit

This sequence turns the six-year retention rule in 45 CFR 164.316(b)(2)(i) into a working system: every Security Rule document and record is inventoried, owned, dated and kept in storage that preserves its history. The result is a retention schedule an auditor can trace from each item back to its creation or last effective date.

Inventory every Security Rule document and record
List every written policy, procedure and plan the Security Rule requires, along with every record of an action, activity or assessment the rule says to document. Include risk analyses, risk management plans, training logs, access reviews, incident reports, sanction records and contingency test results, and note where each one lives today. Done means the inventory names each item, its type, its current location and whether it is still in use, reviewed by the security official and a second person who checks it against the rule's standards.
Assign owners and record effective dates
For each inventory entry, name one accountable owner who creates, approves and retires the item, and record the date it was created and each date it took effect. Owners are usually the security official for policies and the teams that perform the activity for records. Done means every entry has an owner, an approval record and a complete date history, so the later of creation or last effective date can be read directly from the file rather than reconstructed later.
Set the retention schedule from the later date
Write a retention schedule that applies the six-year period in 164.316(b)(2)(i) to each item, counted from the later of its creation date or the date it last was in effect. Record the calculated retention end date beside each entry and state the rule in plain terms so staff apply it the same way. Done means the schedule is signed off by the security official and legal or compliance, and a worked example for a superseded policy is included to show how a revised document carries its own clock.
Configure versioned storage with protected history
Store policies, procedures and records in a system that keeps every revision, records who changed what and when, and prevents silent overwriting or deletion of prior versions. Wiki platforms such as XWiki keep page version history and allow comparison and rollback, and document platforms such as BookStack use role-based permissions that can restrict who may edit or delete. Audit logging for file stores, such as Nextcloud's admin_audit app writing to audit.log, adds a second trail. Confirm with the vendor whether each product can block deletion of prior versions, because version history alone may not satisfy an immutability expectation. Done means a test edit and a test deletion both leave a visible trace.
Restrict deletion to the retention process
Define who may remove a document or record, and under what condition, so that deletion happens only after the retention end date has passed and the schedule approves it. Apply this through role permissions and, where the platform supports it, a separate approval step that is itself logged. Done means the deletion procedure is written, the permission model matches it, and a sample deletion request before the end date is refused or escalated.
Test retrieval against an audit request
Run a timed exercise in which the security official asks for a named policy as it stood on a past date, plus a record from several years earlier, and the team produces both from the storage system. Check that the retrieved version matches the approved original and that its effective dates are visible. Record any gaps, such as missing approvals or unrecoverable older versions, and fix them before closing. Done means the test is written up with the request, the result and the corrective actions, and the team confirms it can reproduce this for every category in the schedule. Confirm with the auditor the form of evidence they expect.
Document and maintain the retention schedule
Publish the final schedule, the owner list, the storage configuration, the deletion procedure and the test results as one controlled set of Security Rule documentation. Set a review point so the schedule is updated when systems, owners or the rule itself change, which connects to the periodic update duty in 164.316(b)(2)(iii). Done means the package is approved, versioned and stored under the same six-year rule it describes, and the security official can show when it was last reviewed and what changed.

Keeping documentation retrievable for six years

A wiki or knowledge base suits the written policies and procedures that the Security Rule requires you to keep for six years. The useful question for an assessor is whether an earlier version of a policy can be produced with its effective period visible. Version control answers that question because each change is stored as a separate revision rather than overwriting the previous text. XWiki is one example of a self-hosted wiki that records every change to a page under version control, so you can see what changed, when and by whom, compare any two versions and roll back to an earlier one.

Change history: Each revision records what changed, when and by whom, which supports the date of creation and the date each version was last in effect.
Version comparison: Reviewers can compare any two versions, which helps show what changed during an annual review.
Rollback: Restoring an earlier version is a recorded action, so the restore itself is visible in the history.
Export and backup: Confirm how revisions are exported and backed up, since retention depends on the history surviving a server migration.

Confirm with the vendor or your platform team whether revisions can be deleted by administrators, whether purge options exist, and how the history is preserved during upgrades. Check that the wiki retention settings do not prune old revisions automatically.

Records of required actions, such as access reviews, log reviews and security configuration changes, need a store that keeps the event itself, not only a summary. Two kinds of audit log serve this purpose in a self-hosted environment. Nextcloud's admin_audit app writes additional event information to a dedicated audit log file, and OpenBao audit devices keep a detailed JSON record of API requests and responses. Both help show that an action happened, but each covers a different part of the environment and needs its own retention plan.

Application events: The admin_audit app logs additional event information to audit.log in the data directory, or to a path set with logfile_audit.
Secrets and API activity: OpenBao audit devices record every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256.
Sensitive values: Hashing of sensitive fields in OpenBao protects the record while preserving evidence that a request occurred.
Separate storage: Move log files to a location with its own retention and backup schedule so they are not lost during routine log rotation.

Confirm with the vendor how log rotation works, how long logs remain in the default path, and whether the audit log path is protected from tampering. Test that a six-year retention schedule actually keeps files readable after rotation and storage changes.

What meeting the six-year retention rule costs

This table breaks the cost of keeping Security Rule documentation for six years into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up. No figures are supplied for this requirement, so use the table to structure quote requests rather than to estimate a budget.

Cost component	Who is paid	One-time or recurring	What drives the cost
Retention schedule design	Internal compliance lead or an outside consultant or implementation partner	One-time, with periodic revision	Number of document types, number of systems holding them, and how many existing records need mapping
Archive and versioning build	Platform engineering or an implementation partner configuring the wiki, file or logging systems	One-time build, then ongoing administration	Choice of platform, number of repositories, and whether version history is already on by default
Storage and backup capacity	Infrastructure team or cloud provider, paid per capacity used	Recurring, growing with every retained version	Document volume, change frequency, log verbosity, and how many backup generations are kept
Ongoing review and purge controls	Internal staff, with partner support if retained under a service agreement	Recurring, tied to review cycles and the Security Rule update duty	Frequency of policy change, the number of owners, and how exceptions and legal holds are handled
Access and audit log retention	Infrastructure or security operations team	Recurring, often the largest storage line for log-heavy systems	Log volume, log format, and whether logs must be kept for the same six years as the documents they support
Optional external review	Independent assessor or consultant, paid per engagement	Occasional, tied to an assessment or audit	Scope of the review, number of records sampled, and whether the reviewer tests retention or only reads the schedule
Staff training on retention rules	Internal training owner or outside trainer	Recurring with staff turnover	Headcount, role changes, and how many teams create Security Rule documents

Open-source platforms that keep version history and audit trails

Retaining Security Rule documentation for six years depends on systems that can prove what a policy said on a given date and who changed it. The four platforms below each cover a different slice of that evidence: document history, access rules, file and admin event logs, and secrets access logs. None of them applies a six-year retention period on its own, so the organization must configure retention and keep copies outside any single tool.

Document version history in XWiki

XWiki keeps every change to a page under version control, recording what changed, when and by whom. Staff can compare any two versions and roll back to an earlier one, which supports showing what a policy said on the date it was in effect. Check that page history is never pruned by a cleanup job, and confirm with your administrator that the retention window for old revisions meets the six-year period for policies and procedures. XWiki is licensed under LGPL-2.1-or-later.

Role-based access in BookStack

BookStack assigns user abilities through roles and lets administrators override permissions per role at the shelf, book, chapter or page level. This matters for documentation because the people who maintain policies should be able to edit them while others can only read. Record who holds each role and review those assignments on a schedule, since the audit trail only helps if the permissions behind each edit are sound. BookStack is licensed under MIT.

Admin event logs in Nextcloud

The admin_audit app in Nextcloud writes additional event information to audit.log in the data directory, or to a path you set with logfile_audit. Use it to show who uploaded, changed or shared policy and record files stored in Nextcloud. Confirm that the log path sits on storage with its own backup, and that rotation does not delete entries that fall inside the six-year window. Nextcloud is licensed under AGPL-3.0-only.

Secrets access logs in OpenBao

OpenBao audit devices record a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, so the log shows that an action happened without exposing the secret itself. This gives evidence of who accessed encryption keys or credentials and when, which supports records of required activities. Enable at least one audit device before production use, and decide where its logs are shipped and how long they are kept. OpenBao is licensed under MPL-2.0.

Who owns retention, who builds it, and what the auditor checks

The covered entity or business associate owns the Security Rule documentation and the obligation to keep it for the required period. Under 45 CFR 164.316(b)(2)(i), the six-year clock runs from the date a document was created or the date it last was in effect, whichever is later, and it applies to both written policies and procedures and records of required actions, activities and assessments. Only the organization can decide what counts as a document, when a version has been superseded, and when a record may be purged. Its responsibilities include:

Retention policy and schedule: Naming each document class (policies, risk analyses, access reviews, training logs, incident records) and the trigger date that starts its six years.
Purge sign-off: Approving every deletion, with the reason, the date and the name of the approver, and confirming no legal hold or open investigation applies.
Ownership of the "last in effect" date: Recording when each policy version was replaced so the later of the two dates can be proven.
Staff accountability: Assigning a named owner for each document class and a backup for absences.
Vendor oversight: Confirming that any hosting or backup provider keeps copies for the same period.

Before any engagement starts, confirm that these decisions are written down and signed by someone with authority over the Security Rule program.

An implementation partner prepares the systems that hold the documentation and the evidence that shows they work. DeployOpen, for example, configures self-hosted platforms inside the client's own infrastructure and does not own the retention decision or issue any assessment result. Typical build work covers version history, access control, audit logging and retrieval tests, and the partner's role ends once the client accepts the evidence. Typical deliverables include:

Versioned storage: Configuring a wiki or document platform so every change is recorded with its author and time, and prior versions can be compared and restored. XWiki documents this kind of version control.
Access and permissions: Setting roles so that only authorized staff can edit or delete controlled documents, with overrides applied at the book or page level in tools such as BookStack.
Audit logging: Routing administrative events to a protected log, such as the admin_audit app and logfile_audit setting in Nextcloud, and confirming the log outlives the documents it describes.
Retrieval tests: Running scripted restore drills that pull a six-year-old version from backup and show it opens with its metadata intact.
Evidence packs: Preparing the retention schedule, configuration exports, log samples and test results for the client and its assessor.

Confirm with the partner which of these items are in the fixed scope and what the client must maintain afterward.

Where six-year retention usually breaks down

Most organizations keep some Security Rule documentation, but the six-year clock fails in predictable places: the start date, the versions, the storage location and the proof of past activity. Each card below names one gap, why it matters for 164.316(b)(2)(i) and the check that closes it.

Clock started at file save date

Teams often count six years from the last time a file was edited or re-saved. The rule counts from the date a document was created or the date it last was in effect, whichever is later. Records of superseded policies can therefore expire earlier than staff expect. Check each document's retention date against its effective date and the date it was replaced, and record both in the document header or in a register.

Superseded versions deleted early

Cleanup routines often remove old drafts and prior policy versions to reduce clutter. When a policy changes, the earlier version is still Security Rule documentation and must be kept for the required period after it was last in effect. Confirm that your document system archives prior versions instead of overwriting them, and that deletion jobs exclude documentation records.

Policies held only in email or drives

Policies circulated as email attachments or stored in personal folders disappear when staff leave or mailboxes are purged. Without a controlled repository, you cannot show which version applied on a given date. Move final policies into a managed system with an owner, approval history and access controls, and keep a dated index that points to each version.

Lost training and access review records

Records of training completion, access reviews, risk analyses and sanction actions are often held in tickets, spreadsheets or HR systems with short default retention. The rule requires records of required actions, activities and assessments for the same period as the policies that govern them. Inventory each recurring activity, name its record owner and confirm the retention setting in every system that holds these records.

Logs rotated before the window closes

Audit logs and access records are frequently rotated or overwritten on short cycles set for operations, not compliance. If a log is the only evidence that a required activity happened, its loss can leave a gap in the documentation trail. Set log retention and archive destinations deliberately, and confirm with your platform team which logs feed evidence of required activities.

Retention never tested by retrieval

Many organizations believe records are kept until someone needs them in an investigation, which is when they discover missing files, broken links or inaccessible backups. Schedule a periodic retrieval test that pulls a sample of documents from several years back, confirms they open, show the correct version and carry their dates. Record the test result as its own piece of documentation.

Questions buyers ask about HIPAA documentation retention

How long must HIPAA Security Rule documentation be kept, and when does the clock start?

Security Rule documentation must be retained for six years. The clock starts at the date the document was created or the date it was last in effect, whichever is later. A policy that was replaced in 2025 therefore stays on file until six years after its last effective date, not six years after the original draft. The retention covers two kinds of material: written policies and procedures, and records of required actions, activities and assessments, such as risk analysis outputs, training logs and incident records. Keep superseded versions as well as the current one, because an assessor may ask what was in effect on a given date. Confirm with your counsel how your state law or other contracts extend these periods, since HIPAA sets a floor, not a ceiling.

Does the HIPAA Security Rule require a specific tool for keeping documentation?

No. The rule requires that documentation be retained and available, and it allows written documentation to be electronic. It does not name a document management product, a file format or a storage location. Any tool works if it keeps every version, preserves the date each version was in effect, limits who can change or delete records, and lets authorized staff retrieve what they need within the retention period. Version history and audit logging are the features assessors look for, because they show that a retained record was not silently edited. Wiki platforms such as XWiki keep version history for every page change, and BookStack assigns permissions per role. Nextcloud's admin_audit app can write audit events to a log file. Evaluate each tool against the retention and availability requirements, and confirm its exact behavior in your own environment before relying on it.

How much effort does keeping six years of HIPAA documentation take, and what drives it?

The effort is mostly ongoing discipline rather than a one-time project. The main cost drivers are the number of Security Rule procedures your organization maintains, how often they change, how many systems generate required records, and whether retention is handled by a system or by staff. A small practice with a few policies and an annual risk analysis carries a light load. A hospital system with many business units, many ePHI systems and frequent change carries a heavier one. Costs fall into three buckets: staff time to file, tag and review records; storage and backup for the retained material; and periodic checks that old records are still readable and complete. Ask any provider to quote these buckets separately, and to state which parts are one-time setup and which recur each year.

How long does it take to set up a compliant documentation retention process?

No duration is supplied for this work, so no timeline can be stated here. The time depends on how many policies and records you already have, whether they are scattered across shared drives and email, how many people must approve changes, and how much existing material needs to be migrated and version-stamped. Ask for a timeline in the written scope of work, with milestones tied to deliverables such as an inventory of Security Rule documents, a retention schedule, the chosen tool configured with version history and access controls, and a staff procedure for filing records. A fixed-scope agreement makes these dates reviewable before work begins.

Can our own team manage HIPAA documentation retention without outside help?

Yes, many organizations do, provided someone owns the process and understands what the rule requires. The work needs a named owner, usually the security official or a delegate, a complete inventory of required documents and records, a retention schedule that counts six years from the later of creation or last effective date, and a routine check that records are being filed. Small teams often struggle with the inventory and with keeping superseded versions, not with the tool itself. An outside partner can help by preparing the system, configuring version history and audit logging, and documenting the procedure, while your organization keeps ownership of the policies and the decisions in them. Decide which parts you will carry internally before you request a quote.

Can an outside partner certify that our HIPAA documentation meets the rule?

No. HHS states that no Security Rule standard requires an entity to certify compliance, and HHS does not endorse or recognize private organizations' certifications. A certification from a vendor or consultant also does not prevent HHS from later finding a violation. DeployOpen prepares systems, controls and evidence, including retention configuration and procedures, but it does not issue audit reports, attestations or certifications. Your organization owns its compliance program. Any third-party assessment can only describe what was tested on a given date, and you should read its scope and limits carefully. HHS's Office for Civil Rights enforces the rule through complaints, compliance reviews and audits, so the record you can produce for an investigator matters more than any badge.

What happens if we cannot produce six-year-old HIPAA policy versions during an investigation?

Missing documentation weakens your position in any OCR complaint investigation, compliance review or audit, because you cannot show what policy was in effect when an incident occurred. The rule's retention requirement is a documentation duty in its own right, so a gap is a compliance finding even when no breach has happened. Civil money penalties are inflation-adjusted each year. For penalties assessed on or after January 28, 2026, the range for violations on or after February 18, 2009 runs from $145 per violation with no knowledge to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294 (45 CFR 102.3, 91 FR 3666). Ask counsel how these ranges apply to your facts.

How DeployOpen prepares six-year documentation evidence

DeployOpen plans, implements and documents the retention setup for Security Rule documentation inside your own infrastructure, under a written fixed scope agreed before work starts. In practice that means configuring self-hosted platforms so that policy and procedure versions, and the records of required actions, activities and assessments described in 45 CFR 164.316(b)(1), are kept for the six years that 164.316(b)(2)(i) requires, counted from creation or from the date each document last was in effect, whichever is later. The scope should name each repository, each record type and the retention rule applied to it, so an assessor can trace a single document from creation through its last effective date to the end of its retention window.

The configuration work usually covers the wiki or document platform that holds policies (for example, version history that records what changed, when and by whom), the access model that determines who can edit or delete retained records, and the audit logging that shows who touched them. Platforms such as XWiki and BookStack can keep version history and role-based permissions, while Nextcloud's admin_audit app writes events to a log file that you choose the location for, and OpenBao audit devices record API requests in JSON. DeployOpen also sets up a retrieval test so that a sample of documents from several years back can be restored and read. Ask the implementation partner to show which settings enforce deletion blocks and which only rely on procedure, and confirm each one with your own platform's documentation before go-live.

DeployOpen does not issue attestations or certifications. It prepares systems, configuration records and evidence for your assessor, and the organization owns its controls, its policies and the decision on how long each record is kept. HHS states that no Security Rule standard requires certification, so there is no DeployOpen or third-party document that proves six-year retention on its own. Your compliance lead should decide the retention rule, approve the written procedure that states it, and confirm with legal counsel whether any state law or contract requires a longer period. The fixed-scope agreement should list who approves retention rules, who holds the admin credentials and what evidence is handed over at the end.

164.316(b)(2)(i) Time limit