164.316(b)(1) Documentation: requirements and evidence

What 164.316(b)(1) documentation requires and why auditors start here

164.316(b)(1) requires a covered entity or business associate to keep Security Rule policies and procedures in written form, which may be electronic, and to keep a written record of every action, activity or assessment the rule requires to be documented. For a compliance lead, this is the standard that turns the rest of the Security Rule into something an investigator can check. The risk it addresses is simple: a control that exists only in someone's memory cannot be verified, handed to a successor, or repeated the same way twice. If a risk analysis, an access review or a workforce training cycle happened but left no record, an OCR investigator has no basis to credit it, and the organization has to reconstruct its position from email and tickets after the fact. HHS OCR's risk analysis guidance points to this standard for the ePHI inventory, the threats, the vulnerabilities and the security measures identified in the analysis, which shows how central it is to the rest of the program.

The difficulty is that documentation rarely sits in one place. Policies may live in a shared drive, the asset inventory in a configuration database, access approvals in a ticketing system, and training completions in an HR platform, each owned by a different team and each changing on its own schedule. A reviewer then has to find out which version was in force on a given date and whether anyone could have followed it. Before starting remediation work, a compliance lead should inventory where each required record is created, who owns it, and where it is kept. That inventory is the working plan for the standard.

This page covers the standard itself. The three implementation specifications under 164.316(b)(2), which are time limit, availability and updates, are explained on their own sibling pages. Unlike many safeguards, this standard is not addressable: all three specifications are required, so an organization cannot decide that documenting a required activity is unnecessary. Confirm the current text of the standard in the eCFR entry for section 164.316(1)) before finalizing internal procedures, since the proposed revision discussed elsewhere in this pillar could change documentation expectations.

Which systems, records and teams fall under the documentation duty

Section 164.316(b)(1) reaches every Security Rule policy, procedure and record, so the scope you draw determines how much paperwork exists and who must maintain it. The cards below cover the decisions that most change the workload: which ePHI systems are in scope, which assessments produce required records, who owns each document, and how business associates and subcontractors fit.

Every ePHI system and its safeguards

Each system that creates, receives, maintains or transmits electronic protected health information needs documented safeguards, including the configuration, access rules and encryption settings that apply to it. Teams often document the core electronic health record and miss the scheduling tool, the billing export, the file share and the laptop fleet. Ask for a current inventory of ePHI locations before you estimate the documentation effort, because every missing system is a gap in the written record.

Risk analysis outputs as required records

OCR's risk analysis guidance cites 164.316(b)(1) for documenting the ePHI inventory, the threats, the vulnerabilities and the security measures identified in the analysis. The risk analysis is therefore a documentation event, not only a technical exercise. Confirm that the analysis, its inventory and its risk management decisions are stored as versioned records that can be retrieved years later.

Evaluations, incidents and contingency records

Periodic evaluations, security incident responses and contingency plan tests each generate outcomes that the rule expects you to document when they are required actions. A tabletop exercise with no written findings or a closed incident with no record of response steps leaves a hole in the audit trail. Decide in advance which events trigger a written record, who signs off on it and where it is filed.

Named owners for each document

The security official, system owners, HR, facilities and privacy staff each hold pieces of the required documentation, and a document with no owner usually goes stale first. Assign one accountable owner per policy, procedure and record, and write that assignment into the document itself. Ask who approves changes and who confirms that the workforce can reach the current version.

Business associates and subcontractors holding ePHI

A business associate that creates, receives, maintains or transmits ePHI for a covered entity is subject to the Security Rule and must document its own safeguards. Where that business associate uses subcontractors that handle ePHI, the chain continues, and each link has its own documentation duty. The covered entity should confirm that its contracts require vendors to produce and retain these records, and that it can obtain them on request.

Systems that carry no ePHI

Scoping in only the systems that touch ePHI keeps the documentation set manageable, but the boundary has to be defended. Network segments, identity services and monitoring tools that protect ePHI systems often fall inside the Security Rule's reach even when they never store patient data. Document the boundary decision itself, with the reasoning, so an assessor can see why a system was excluded.

How an assessor tests the documentation standard

This table walks through how an assessor tests 164.316(b)(1), from requesting the policy set to sampling records against system change history. Read each row as a test step paired with the evidence it produces and the gap that most often shows up. Keep in mind that OCR audit and investigation outcomes come from OCR's own process, and no certificate or third-party document replaces them.

Test step	What the assessor does	Evidence requested or common finding
Request the policy set	Asks for the complete set of written Security Rule policies and procedures with version history and approval records	Finding: policies cannot be produced on request, or the set has gaps against the rule's standards
Map requirements to procedures	Checks that each Security Rule requirement has a written procedure that fits the entity's size and ePHI environment	Finding: a required safeguard has no procedure, or procedures describe systems the entity no longer runs
Sample documented actions	Selects a sample of actions and assessments the rule requires to be documented, such as risk analysis outputs and access reviews	Evidence: dated records showing who performed the action, what was found and what was done
Compare practice to documents	Interviews staff and checks systems to confirm that the written procedures are followed in daily operation	Finding: policies exist but are not followed, which is one of the most frequent gaps
Check dates and versions	Compares document revision dates against system changes, new vendors, staff turnover and incidents	Finding: documents were not updated after a material change to ePHI systems or workflows
Test retention and access	Confirms records are kept for the required period and that responsible staff can retrieve them	Evidence: retention schedule and retrieval test. Finding: records were discarded early or only one person can locate them
Review missing assessments	Looks for evidence that required assessments were performed and documented, including the scope and findings	Finding: no record of a risk analysis or evaluation, or assessments that are undated or unsigned
Confirm independent outcomes	Records findings in its own process. Audit and investigation outcomes come from OCR, not from any private certificate	Ask your team to confirm the current OCR audit and enforcement process before relying on any third-party attestation

How to build the documentation set step by step

This sequence turns the Security Rule's documentation duty under 164.316(b)(1) into a working set of written procedures and dated records that an assessor can trace back to each requirement.

Inventory every Security Rule requirement
Start by listing each standard and implementation specification in Subpart C, including the administrative, physical, technical, organizational and documentation standards. For each one, note the action, activity or assessment it requires to be documented, such as the risk analysis, periodic reviews, training and access reviews. Mark which specifications are required and which are addressable, and record the documented reason for any addressable specification you decide not to implement as written. The output is a requirement register with one row per requirement and a column for the record it implies. The step is complete when someone outside the project can read the register and see where every requirement is covered or why it is not.
Assign an owner for each document
Give every policy, procedure and record in the register a named owner who is accountable for accuracy and for the review cycle. Owners are usually the people who run the control day to day, such as IT operations for backup procedures or HR for workforce sanctions, with the security official coordinating across them. Record the owner, the backup owner and the approver in the register. Confirm each owner has agreed in writing, since ownership gaps are a common reason documentation goes stale. The output is a complete owner column with no blanks.
Draft and consolidate the procedures
Write one procedure for each control activity, scaled to the size and complexity of the entity as the rule allows. Merge overlapping documents, such as several access policies that repeat the same steps, so that each instruction exists in one place and is cross-referenced elsewhere. Describe what is done, by whom, how often and where the resulting evidence is stored. Avoid copying regulatory text into procedures; state the organization's own practice. The output is a set of draft procedures, each with a version number, a status and a link back to the requirement it supports.
Set up a single controlled repository
Place all policies, procedures and records in one repository that tracks version history, records what changed, when and by whom, and allows comparison and rollback between versions. Restrict edit rights by role so that owners can update their documents while others can read them. Confirm the platform's audit trail and permission model before relying on it, because capabilities differ between tools. Open-source wiki and documentation platforms can meet this need when they are configured and backed up correctly. The output is a live repository with the approved documents loaded, access roles defined and version history switched on from the first publication.
Capture completed actions as dated records
Each time a documented activity happens, create a dated record that shows who performed it, what was found and what was done. Examples include the completed risk analysis, periodic evaluation results, training attendance, access review sign-offs, incident reviews and sanction decisions. Store these records in the same repository or a linked system with equal retention controls, and tie each one to the requirement and procedure it satisfies. The output is a dated evidence file for every activity in the register, with no activity recorded only in someone's memory or email.
Run a first completeness check
Walk the requirement register line by line and confirm that each row points to a current procedure, an owner, and at least one dated record where the rule calls for an action to be documented. Note gaps, outdated versions and records that are missing a date or approver. Ask someone who did not write the documents to try to trace one requirement from the register to its evidence, since this exposes unclear wording quickly. The output is a gap list with an assigned owner and due date for each item, and a sign-off from the security official that the register reflects current practice.
Confirm the check with an independent reviewer
Before relying on the documentation set, ask whether the review should be performed by an outside party. Internal completeness checks catch many gaps but cannot provide independent assurance, and HHS does not certify compliance or recognize private certifications. Any outside assessment should be scoped in writing and performed by a qualified assessor, and its findings are the assessor's, not the consultant's. Ask for a written statement of what the review covered and what it did not. The output is a documented decision on independent review, with the scope and results filed in the repository.

Which evidence artifacts pass the documentation test

Under 164.316(b)(1), an assessor looks for proof that Security Rule documentation exists, reflects how the environment actually runs, and was kept current. The artifacts below are what connects a written policy to a verifiable record. Each one answers a different question an assessor will ask.

Written policy and procedure set

The core documents that describe how each Security Rule requirement is met, including who performs each task and how often. Check that every policy maps to a standard or implementation specification and that procedures name current roles rather than former employees. Confirm the set is written in a form the workforce can find and follow. Electronic documents are acceptable, so the question is whether the format is controlled, not whether it is paper.

Risk analysis record with ePHI inventory

HHS OCR's risk analysis guidance cites 164.316(b)(1) for documenting the ePHI inventory, the threats and vulnerabilities identified, and the security measures chosen in response. Assessors compare this record against systems actually in use, so a stale inventory that omits cloud services or removable media is a frequent finding. Confirm the analysis names where ePHI is created, received, stored and transmitted, and that each identified risk links to a measure or a documented decision to accept it.

Dated records of security activities

Each action or assessment the rule requires to be documented needs its own dated record: access reviews, training completions, security incident reviews, contingency plan tests and evaluations. An assessor will pick a sample and ask for the record behind it. Confirm each entry shows the date, the person who performed the activity, the result and any follow-up. A policy that promises quarterly reviews fails if no review record exists for the quarters claimed.

Version history of changes

Version history shows what changed in a policy or procedure, when, and by whom, which lets an assessor confirm that the document in force was the one applied during a given period. This matters because documentation must be updated after environmental or operational changes. Platforms such as XWiki keep every change under version control and allow comparison and rollback. Confirm the history is retained for the full retention period, not trimmed when pages are edited.

Access logs to the documentation repository

Access logs show who could view, edit or approve Security Rule documentation, which supports both the availability requirement and the integrity of the record. Role-based permissions, such as those in BookStack, let teams restrict editing to designated owners while keeping reading open to the people who run the procedures. Confirm logs record edits and approvals, that permissions are reviewed, and that the repository itself is covered by the same access controls as the ePHI it describes.

Keeping evidence current between audits

Most gaps come from records that were accurate at the last audit and then drifted. Tie each artifact to a recurring trigger: a change ticket, a scheduled review, or a system onboarding step that requires an inventory update. Assign an owner to each document and a review date, so updates happen as work is done rather than rebuilt before an assessment. Confirm with the organization's own tooling how these triggers are recorded, since the mechanism matters more than the template.

What meeting the documentation requirement costs in money and effort

This table lists each cost component of keeping 164.316(b)(1) documentation current, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request or an internal budget. No fee or duration is stated because no researched figure applies, so ask each provider to price the components separately.

Cost component	Who is paid or who bears it	One-time or recurring	Main cost drivers and what to request in a quote
Drafting policies and procedures	Internal security, compliance or privacy staff, or a consultant if bought	One-time for the first set, then recurring as revisions occur	Number of Security Rule requirements in scope and number of systems each procedure covers. Request a list of deliverables, the page count per procedure and the review rounds included.
Maintaining and updating documents	Document owners across IT, clinical operations, HR and facilities	Recurring	Change frequency of environments, vendors and workforce roles. Ask who owns each update, how changes are triggered and how many review cycles are included.
Repository or wiki tooling	Software vendor for licensed tools, or internal platform team for self-hosted open-source tools	Licensing is recurring for commercial tools. Open-source tools remove license spend but keep hosting, backup, patching and administration as recurring work.	Number of users, access roles and retention needs. Confirm the license model, hosting location, backup method and who patches the server before comparing options.
Version control and access configuration	Internal administrators or the implementation partner who configures roles	One-time setup, then recurring administration	Number of document classes and approval paths. Request a description of how version history, rollback and role-based permissions are configured and tested.
Producing activity and assessment records	Operations staff who perform the activity, such as access reviews, training sessions and drills	Recurring	Number of activities the rule requires to be documented and how many are run per year. Ask how records are captured at the source to avoid rebuilding them later.
Retention and availability management	Internal records or IT staff, plus storage costs where records are held in your own infrastructure	Recurring	Volume of retained records across the six-year period and the number of people who need access. Confirm storage growth, backup coverage and how records remain retrievable after staff changes.
Internal review and sign-off	Security official, privacy officer and business owners	Recurring	Frequency of scheduled reviews and the number of approvers per document. Ask whether the vendor or consultant includes a review of drafts and what the sign-off workflow looks like.
External review or consultant time	Independent consultant or assessor, paid by the hour or under a fixed-scope agreement	Often one-time for a gap review, recurring if used for periodic review	Scope of documents reviewed, whether drafts are written or only checked, and whether the consultant prepares evidence or only advises. Ask for a written scope and deliverables before work starts.

Which self-hosted open-source tools can hold Security Rule documentation

Under 164.316(b)(1), written policies, procedures and records must be kept and made available, so the tool you choose has to preserve history, control who sees and edits content, and hold assessment records. The three tools below cover different parts of that job, and none of them makes an organization compliant on its own.

Version-controlled documentation with XWiki

XWiki is an open-source wiki (LGPL-2.1-or-later) that keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. This history helps show that a policy was in effect on a given date and that updates followed environmental or operational changes. Check that the version history is retained for the six years the time limit requires, and that backups capture page history, not only current content.

Role-based access in BookStack

BookStack (MIT) organizes content into shelves, books, chapters and pages. User abilities come from assigned roles, and permissions can be overridden per role at the shelf, book, chapter or page level. This lets a security official edit the risk management procedures while workforce members get read-only access to the sections that describe their duties. Confirm that the role design matches who is responsible for each procedure, and that access reviews are recorded.

Framework assessments in CISO Assistant

CISO Assistant (AGPL-3.0-only) is a governance tool that ships with more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and runs audits and compliance assessments against them with automatic mapping between frameworks. It can hold assessment records and evidence links for Security Rule work, but it does not ship a HIPAA Security Rule framework in the supplied facts, so confirm whether a HIPAA mapping exists or would need to be built. The AGPL-3.0-only licence requires legal review before you modify or offer the software to others.

Matching tools to document types

Policies, procedures and assessment records have different owners and change rates, so one tool rarely fits all of them. A wiki with version history suits frequently updated procedures, while a governance tool suits assessment results that map to controls. Decide which system is the authoritative copy of each document, and state that in the documentation itself. Ask the implementation partner to document the chosen design, including how records move between systems.

Confirming fit before adoption

Whether a tool meets your needs depends on your controls, retention rules, hosting and audit expectations, none of which a feature list can settle. Before adoption, test version restoration, export formats, backup and restore of history, and whether logs of permission changes are kept. Ask the vendor or community to confirm each capability you depend on, and record the test results. Independent assessors will ask for this evidence, not the tool's marketing claims.

Who owns the documentation work, who helps and where the auditor stops

Your organization owns the Security Rule documentation. Under 45 CFR 164.316(b)(1), the written policies, procedures and records are the entity's own obligation, and no outside party can take that responsibility over. Your security official and the people who run ePHI systems decide what the procedures say, confirm they match how work is actually done, and approve each version before it takes effect. Several tasks stay in-house in practice because they require knowledge of your operations.

Policy decisions: Leadership sets the risk tolerance, approves policies and assigns owners for each procedure.
Factual accuracy: Staff confirm that procedures describe real systems, real vendors and real workflows.
Sign-off records: Approvers date and sign each version, so you can show who authorized what and when.
Activity records: Operational teams create the logs, tickets, risk analysis outputs and training records the rule expects you to keep.
Retention and review: Someone accountable tracks the six-year retention clock and schedules updates after environmental or operational changes.

Before engaging any partner, confirm that named internal owners exist for each document and that they have time to review drafts.

Where documentation programs usually fall short

Most documentation failures under 164.316(b)(1) are not missing files. They are policies that describe a different environment, procedures nobody owns, and records that cannot show when something happened or who approved it. Each card below pairs one common gap with a closing step you can check.

Templated policies that ignore real systems

A policy copied from a template may name tools, roles or data flows the organization does not use. Assessors compare the written procedure with what staff actually do, and a mismatch is treated as a documentation failure even when the controls work. Rewrite each policy against your current ePHI inventory, then have the people who run the systems confirm each step is accurate.

Procedures with no named owner

A procedure that says the security team will review access is hard to defend when nobody on that team knows it is theirs. Each procedure should name one accountable role and a backup, with the date it was last reviewed. Check that every owner has seen the document and can explain their step without looking it up.

Activity records missing dates or sign-off

Records of reviews, training completions and risk assessments often exist as notes without a date, reviewer or outcome. Under 164.316(b)(1), the written record must show that the required action or assessment happened. Use a fixed template with fields for date, person, scope and result, and require a signature or ticket reference before a record is filed.

Documents kept in personal drives

When policies sit in an individual's downloads folder or a personal cloud account, they disappear with the employee and cannot be found during an incident or audit. Keep all Security Rule documentation in one controlled repository that the organization owns, with access granted by role. Confirm that departing staff lose access and that the repository is included in your backups.

No version history or change trail

Without version history, you cannot show which policy was in effect on a given date, which is what the six-year retention requirement depends on. Open-source wikis such as XWiki record every change with the time and author and allow comparison and rollback. Confirm that your chosen tool keeps this history and that exports preserve it.

Questions buyers ask about documenting HIPAA Security Rule requirements

How much effort does HIPAA Security Rule documentation take?

Documentation effort scales with the size of your environment and how many systems touch electronic protected health information. Under 164.316(b)(1), you need written policies and procedures for every Security Rule requirement, plus a written record of each action, activity or assessment the rule says to document. The largest share of work is usually the first pass: inventorying systems, writing procedures that match how your staff actually work, and recording the risk analysis results. After that, the recurring effort is keeping records current as systems and staff change. Ask any provider to break its estimate into the initial build and the ongoing upkeep, and to state which documents it expects your team to review and approve.

Can an in-house team document HIPAA Security Rule requirements?

Yes, a covered entity or business associate can write and maintain its own documentation, and the rule does not require an outside firm. The Security Rule is written to be scaled to the organization's size, complexity and capabilities. An in-house team needs staff who understand both the rule and the company's systems, time for reviews, and a named owner for the security program. Many organizations find the hardest part is not writing but keeping procedures accurate after systems change. Outside help is most useful for a gap review, drafting templates, or preparing evidence for an independent assessment, while the organization keeps ownership of its decisions and sign-off.

How long does it take to build the first set of Security Rule documents?

The duration depends on how many systems hold ePHI, how much existing policy you already have, and how many people must review each document. No supplied source gives a standard duration, so treat any figure you hear as a question to test, not a fact. Work that usually drives the schedule includes the ePHI inventory, the risk analysis, getting business owners to confirm how procedures run, and approval cycles for policies. Ask a provider to show its schedule by phase, name the people it expects from your side, and state what happens if a review takes longer than planned. A fixed-scope written plan makes the timeline easier to hold.

What does HIPAA documentation require from leadership and system owners?

Leadership must approve the policies, assign responsibility for the security program, and fund the work needed to keep documents accurate. System owners must confirm how their platforms run, what access exists, how backups and changes happen, and what records they produce. Under 164.316(b)(1), the written record needs to reflect what the organization actually does, so documentation that only leadership writes often fails when staff do not follow it. Ask for a RACI-style list showing who drafts, who reviews, who approves and who keeps each record. Clear ownership also makes it easier to show an OCR investigator that someone is accountable.

Can a consultant certify our HIPAA documentation?

No. HHS states that no Security Rule standard requires certification, that it does not endorse or recognize private certifications, and that a certification does not prevent HHS from later finding a violation. A consultant can help draft, review and organize your documentation, and an assessor can test it, but neither issues a HIPAA certificate that HHS will accept as proof of compliance. Be cautious with any vendor that offers a HIPAA certificate or seal. Ask what the deliverable is, who signs it, and whether it is an opinion, a gap report or a formal assessment, and keep your own records as the primary evidence for OCR.

How do we keep HIPAA Security Rule documents current?

The third required specification under 164.316(b)(2) requires you to review documentation periodically and update it in response to environmental or operational changes that affect ePHI security. Practically, this means tying updates to change events such as new systems, staff turnover, vendor changes, incidents and risk analysis results. Keep a version history that shows what changed, when and by whom, and set a review schedule that you can actually meet. Open-source wiki tools such as XWiki keep version history and allow rollback, and BookStack lets you set permissions per role, which helps limit edits to approved owners. Confirm any product's audit and access features in your own environment before relying on them.

What does DeployOpen do for HIPAA documentation?

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and it can configure those platforms to hold policies, procedures and records with version control, access roles and backup routines. It can also prepare systems and evidence so your team and an independent assessor can review them. DeployOpen does not write your policies as a substitute for your ownership, does not issue audit reports or certifications, and does not guarantee that any assessment outcome will meet HHS expectations. Scope, deliverables and timelines are agreed in writing before work begins, and a quote follows from that scope.

How DeployOpen prepares documentation evidence for a HIPAA assessment

DeployOpen starts this work with a written scope that names the Security Rule policies and procedures in question, the record types to be kept under 164.316(b)(1), the owners who approve each document, and the systems that will host them. Deployment happens inside the client's own cloud accounts, data center or network, so the repository holding Security Rule documentation stays under the covered entity's or business associate's control. DeployOpen plans and installs a self-hosted wiki or knowledge base, configures roles and permissions so that each document has an owner and a defined editor group, enables version history, and documents the backup and restore approach. Where the client already has a document system, the scope should say whether DeployOpen migrates it or only structures new content. Ask for the list of deliverables and the acceptance criteria before work begins.

The substance of each policy and procedure comes from the client's security official, privacy staff, HR, IT and clinical or operational leaders. DeployOpen can structure templates, draft starting text from the requirement, and map each document to the record types the rule expects, including the ePHI inventory, threats, vulnerabilities and security measures named in HHS risk analysis guidance. The client's owners review, change and approve the final wording, and the client decides what its controls actually do. DeployOpen then prepares an evidence pack: an index of current documents with approval dates and version references, the review history, retention settings and a sample of records showing that procedures were carried out. Retention and update cycles are the client's decisions to set and enforce; the pack shows how they are configured.

DeployOpen does not issue audit reports, attestations or certifications. HHS states that no Security Rule standard requires certification, so the assessor a client chooses, whether an internal auditor, an external firm or an OCR review, decides what the evidence proves. The client owns its controls and is responsible for whether its documentation matches its practice. Before engaging anyone, confirm with the assessor which documents and formats it will accept, how long it expects prior versions to be retained, and whether it wants to see approval records. The NIST SP 800-66 Rev. 2 resource guide lists the documentation activities that a reviewer is likely to test against.