164.316(b)(2)(ii) Availability: requirements and evidence

What 164.316(b)(2)(ii) availability requires in practice

Making Security Rule documentation available is a required implementation specification under the documentation standard in 45 CFR 164.316(b)(2)(ii). It requires that the written policies, procedures and records be made available to the persons responsible for carrying out the procedures they describe. If you have written HIPAA procedures for ePHI, this specification asks a simple question with a demanding answer: can the people who run backups, grant access, respond to an incident or handle a device disposal find the current version when they need it, including outside business hours? The risk this specification addresses is staff working from procedures that are missing, outdated or impossible to find. A help desk technician who cannot locate the access provisioning steps may improvise, and an on-call engineer who cannot open the contingency plan at 2 a.m. may restore systems in a way the documented process never intended. Availability is not met just because a document exists somewhere in the company.

What usually makes this hard is fragmentation. Procedures sit in shared drives, email attachments and personal folders, with several drafts and no single controlled copy. On-call staff, contractors and managed service providers often have no account at all, or hold credentials that expired months ago. Before you plan any fix, check each role that carries a procedure against three questions: do they know where the approved version lives, can they open it from every location and device they work from, and does their access continue during an outage that affects your primary systems? Confirm the answers with the people who would use the documents in an emergency, not only with the system owners who wrote them.

Which documents, people and systems fall under availability

Availability under 164.316(b)(2)(ii) is only as complete as the scope behind it. The decisions below determine which documents must reach which people, where those documents live, and who outside the organization is responsible for making them available.

Security Rule documents in scope

Availability applies to the written policies and procedures that describe how each Security Rule requirement is carried out, along with the records of actions, activities and assessments the rule says to document. Start by listing every procedure the organization relies on for ePHI, such as risk analysis outputs, access reviews, contingency plans and incident response steps. Check that each one has a current version and an owner, because a document that exists but is not the one staff actually use does not meet the requirement.

Roles that carry out each procedure

The people who must be able to read a document are the ones who perform the procedure it describes. For each procedure, record the role that executes it, such as the security official, system administrators, help desk staff, clinicians who handle ePHI or on-call responders. Mapping roles to procedures, rather than giving everyone the full library, shows the assessor that access follows responsibility and that no required performer is left without the material.

Workforce members and clinical users

Clinicians, front-desk staff and temporary workers often perform steps such as reporting a suspected incident or requesting an access change. These steps are procedures too, so the relevant portions must reach them in a form they can find under pressure. Confirm that the sections describing their own tasks are available to them, and that someone can show which version applied on a given date.

Responders and after-hours roles

Incident response, contingency and backup procedures are often needed when the usual administrators are unavailable. Confirm that on-call engineers and backup administrators can reach the runbooks without depending on a single laptop, mailbox or account that may be locked during an outage. Test access from outside the normal network, because a document that is unreachable during a ransomware event fails the purpose of availability.

Where documents are stored and hosted

The hosting decision determines who controls availability. Documents kept on a shared drive, a wiki or a ticketing system each carry different access controls, backup arrangements and retention behavior. For a self-hosted wiki, the organization or its implementation partner operates the platform, while a managed service adds a provider whose terms and uptime must be reviewed. Ask where the authoritative copy lives, whether an offline copy exists, and how the platform's version history is preserved.

Business associates and subcontractors

When a business associate or subcontractor runs a procedure for the covered entity, such as managed IT monitoring or backup restoration, the documentation describing that work must still be available to the people responsible for it. Clarify in writing which party holds the authoritative copy, who may read it, and how the entity can obtain it on request. The entity remains accountable for the procedure even when a vendor performs it, so availability checks should include vendor-operated runbooks.

How availability differs from retention and updates

Availability asks whether the right people can reach the current, applicable documentation when they need it. It is the only one of the three documentation specifications in 45 CFR 164.316(b) that is judged by use rather than by storage or revision history. The six-year time limit in 164.316(b)(2)(i) asks whether superseded versions still exist, and the periodic review in 164.316(b)(2)(iii) asks whether the content was revised after a change in the environment or operations. Neither asks whether the security officer, the help desk lead, the backup administrator or the clinical systems team can open the procedure they are expected to follow during an incident or a staff change.

A single document set has to satisfy all three at once. Take a backup restoration procedure. It must be revised when the backup platform or the ePHI systems it protects change (updates), the superseded versions must be kept for six years from creation or from the date last in effect, whichever is later (retention), and the current version must be reachable by the people who run restores (availability). An archive that is retained but unreachable, such as a folder on a decommissioned file share, a scanned PDF nobody can search, or a wiki where the restoration staff have no read access, satisfies retention and fails availability. The same is true of a current version that is reachable only by the administrator who wrote it. Confirm, for each procedure, who is the responsible role, where the current copy sits, and whether that role can open it during an outage when the usual identity provider or network path may be unavailable.

How an assessor tests availability and what they ask to see

This table lays out each step an assessor typically takes to test whether Security Rule procedures are available to the people who run them, what evidence they request, and where organizations most often fall short. Read it as a pre-audit checklist: if any row produces a weak answer in your environment, fix that gap before an assessor arrives. The main takeaway is that a document existing somewhere is not enough; the right people must be able to reach the current approved version without help.

Test step	What the assessor does	Evidence requested	Common finding
Workforce interviews	Asks responsible roles, such as the security official, system administrators and help desk staff, where they find the procedures they follow and when they last used them.	Named roles and the locations they cite; confirm answers match the repository's actual path.	Staff describe a procedure from memory or name a shared drive that no longer holds the current version.
Access path walkthrough	Asks a responsible person to open the relevant procedure live, starting from their normal login, and records each click or search needed.	Screen walkthrough notes, timing of access and any help required to reach the document.	Procedures exist but are buried in folders or behind permissions the people running them do not hold.
Current version check	Confirms the version displayed is the latest approved one and that superseded copies are marked or removed from working locations.	Version history, approval records and the date of the last review.	Outdated copies sit alongside the approved version, or the approved version was never published to the location staff use.
Repository permission review	Reviews who can view, edit and approve documents in the repository and compares that list to the roles that must use the procedures.	Role and permission exports, access request records and group membership lists.	Responsible staff lack view rights, while edit rights are granted too broadly to people outside the approval chain.
Sampling against systems	Selects several procedures and checks that the steps described match how the systems are configured and operated today.	Sampled procedures, configuration records and short demonstrations by the staff who operate the system.	Procedures describe systems or steps that were changed or retired, so the people following them cannot carry them out.
Copy custody	Asks where a copy lives if the document owner or a single administrator is unavailable and whether another responsible role can retrieve it.	Backup or alternate location records and the list of people with retrieval rights.	The only copy is held by one administrator or on a personal device, so no one else can reach it during an absence.
Access during incidents	Checks whether the procedures needed for incident response and contingency work can be reached when the normal network or identity service is down.	Offline or alternate access arrangements and records of any test of them.	Procedures are reachable only through systems that the same outage would take down.

How to implement availability step by step

This sequence moves Security Rule procedures from an inventory of who runs what to a single controlled location that the right people can reach, confirmed by a test of access. Each step closes with a record you can show an assessor.

Inventory procedures and the roles that run them
Start by listing every written policy and procedure your organization maintains under the Security Rule, then identify which roles must carry out each one, such as IT operations, the security official, clinical managers or facilities staff. The compliance lead or security official usually owns this work, with input from department heads who know how tasks actually get done. The output is a procedure-to-role map that names each document and the people responsible for implementing it. The step is complete when every procedure has at least one responsible role and no role is left unassigned.
Choose one controlled repository
Select a single system of record for approved Security Rule documentation, whether a document management platform, a wiki or a governed file share. The selection should be made by the security official with IT and privacy input, and it should be recorded in the policy that governs documentation. Confirm with the vendor or your own administrators that the chosen tool can keep version history, restrict edits and export records for retention under the six-year requirement. The output is a short decision record naming the repository, its owner and its hosting location.
Assign read access by role
Build an access matrix that maps each role from the procedure-to-role map to the documents that role needs to read, and grant access in the repository to match. Limit edit rights to a small group of document owners so that the people who implement a procedure can read it without being able to change it. Review the matrix with department heads, since a clinical or facilities role may need a different set of documents than an engineer. The output is an access matrix, plus a record of the group memberships or roles created to enforce it.
Publish approved versions
Before anything is placed in the repository for general reading, have the designated approver sign off on each document and record the approval date, version and approver. Publish only the approved version, and mark superseded versions so that staff cannot mistake an old procedure for the current one. Keep the earlier versions in the repository history so that the documentation can be shown as it stood on any past date. The output is an approved publication record listing each document, its version, its approver and the date it went live.
Communicate the location and access process
Tell each role where its documents are, how to request access when it is missing, and who to contact when a procedure is unclear or out of date. Deliver the message through the channels your workforce already uses, such as onboarding, role-based training or a team briefing, and make the access request process part of onboarding for new hires and role changes. Ask each person to acknowledge the access process in writing or through a logged click in your training or HR system. The output is a signed or logged acknowledgment for each workforce member who has been given access.
Test access with a sample of roles
Pick a sample of roles from the access matrix, ideally one from each major function, and have a person in each role try to open every document the matrix lists for them and confirm they cannot open documents outside it. Record the results, including any gaps, and fix them by updating the matrix or the repository permissions before the test is closed. Retest the affected roles after each fix. The output is a dated access test record showing the roles tested, the results, the corrective actions and the retest outcome.

Evidence that shows documentation is available

Availability is shown by records that connect each Security Rule procedure to the people who must carry it out, and by proof that those people could reach the approved version when they needed it. The cards below cover the artifacts that tie documentation to roles, access and workforce awareness, and how to keep each one current between audits.

Procedure-to-role map

A table that lists each written policy and procedure, the workforce roles responsible for carrying it out, and the document location. For 164.316(b)(2)(ii) Availability, this map is the starting point for proving that documentation reaches the people it describes. Check that every procedure has at least one named role and that no procedure is orphaned after a reorganization. Review the map whenever a procedure changes owner, and at the review cadence you set for your program.

Repository access matrix

An export showing which roles can view, edit and approve each document or space in the system that holds your Security Rule documentation. Permissions should follow from role assignments, not from individual grants, so the matrix can be read as a list of who can open what. Confirm that responsible roles have view access to the current approved version. Confirm the matrix matches your procedure-to-role map, and record the date of each export.

Current version access evidence

A dated screenshot or export that shows a responsible role opening the current approved version of a procedure. This is the most direct evidence that documentation is available, because it shows the document is reachable by the person who must follow it, not just stored somewhere. Capture it from a test account or a role-based view, and label which role was used. Refresh it after any change to the repository, the role model or the document's approval status.

Publication record with approvers

A log showing when each policy and procedure was published or replaced, who approved it, and which version it superseded. The record shows that the available version is the approved one and that older versions are retired. Keep the log alongside the documentation, not in a separate tool that may be lost. Add an entry each time a document is published, and check quarterly that no responsible role is still pointed at a superseded copy.

Workforce acknowledgments of procedure locations

Signed or electronically recorded confirmations from workforce members that they know where their procedures are kept and how to access them. These records connect availability to the people who carry out the work, and they show that the organization told them where to look. Ask each new hire during onboarding and each person who changes role to acknowledge the locations for their duties. Keep the acknowledgments with the training records, and confirm your own retention rule for them.

Access review records

Documented reviews of who holds access to Security Rule documentation, with the reviewer, the date, the findings and the changes made. Reviews catch access that lingers after a role change or departure, and they show that availability is maintained as staffing changes. Run reviews on the frequency you set in your own access policy, and always after a role change or termination that affects a documented duty. Retain each review with the date it was completed and the corrective action taken.

What meeting availability costs in money and effort

This table breaks the cost of making Security Rule documentation available into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure a written quote and to see where open-source tooling removes license spend while labor remains. No prices or durations are stated because none were supplied; ask each provider to price every row separately.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Repository tooling or licenses	Recurring if commercial, one-time for setup. Software vendor or cloud provider; self-hosted open-source wiki platforms may carry no license fee but still need hosting.	Number of named users, hosting model, and whether single sign-on and audit logging are included in the tier you choose.
Engineering or administrator time to configure roles and publication	One-time setup, then occasional change. Internal staff or implementation partner, billed by scope.	Number of roles, whether permissions are set per shelf, book or page, and how many publishing workflows are needed.
Time to map procedures to roles	One-time, repeated after major change. Security official, process owners and the implementation partner if one is engaged.	Number of Security Rule procedures in the document set and how many distinct workforce groups each one reaches.
Workforce communication and training time	Recurring at each update, plus onboarding. Internal managers and staff time, which is usually the largest unbudgeted cost.	Workforce size, number of sites or shifts, and how often procedures change.
Evidence upkeep and access reviews	Recurring, typically on a fixed schedule. Internal security or compliance staff.	Whether access is managed centrally through a directory, and how many systems hold copies of the documentation.
External review of the document set	One-time for initial review, recurring when the scope changes. Outside consultant or implementation partner, priced in a written scope.	Document count, prior gap history, and whether the reviewer tests availability or only content.
Auditor sampling time	Recurring at each assessment. Independent auditor or assessor, who alone issues any report.	How many procedures the auditor samples and whether access logs and role lists are ready on request.

Self-hosted open-source wikis that can host and control HIPAA procedures

A wiki can hold the procedures that 164.316(b)(2)(ii) requires you to make available to the people who carry them out. The two options below differ in how they record changes and how they assign access, so the choice affects what evidence you can show an assessor. Neither tool makes your organization compliant on its own.

XWiki version history

XWiki is licensed under LGPL-2.1-or-later and 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 lets you show which procedure text was in effect on a given date. Check that the version history is retained for the six years 164.316(b)(2)(i) requires, and that backups of the wiki database and attachments are tested in your own environment.

BookStack role-based access

BookStack is licensed under MIT and gives each user abilities through assigned roles. Permissions can be overridden per role at the shelf, book, chapter or page level, so the staff who run a procedure can read and edit only the sections they own. Confirm that role assignments are reviewed when people change jobs or leave, because an outdated role is the most common way access drifts from what the documentation intends.

Role assignments as evidence

Role assignments show who could reach each procedure at a given time, which supports the claim that documentation is available to the people responsible for implementing it. Export or screenshot the role configuration at regular intervals and keep it with your access review records. Be aware that a role list alone does not show who actually read a procedure, so pair it with your training and sign-off records.

Hosting and backup responsibilities

Both wikis run in your infrastructure, so availability depends on hosting choices you own: server redundancy, backup frequency, restore testing and patching. Ask who operates the platform, how often restores are tested, and what happens to documentation during an outage affecting ePHI systems. Document the answers as part of your contingency plan, because a wiki that is down during an incident does not make procedures available.

What the tool cannot prove

A wiki supports availability, but it does not satisfy 164.316(b)(2)(ii) by itself. The requirement is met when the right people can reach the right procedures, which depends on your decisions about who needs which content and whether they know it exists. Treat the wiki as one component of your documentation program and confirm hosting, backup and access controls in your own environment before relying on it.

Who owns availability: your team, a partner and the auditor

Under 45 CFR 164.316(b)(2)(ii), the covered entity or business associate is the party that must make documentation available to the people who carry out the procedures it describes. That duty stays with your organization regardless of who helps build the system. Your security official, procedure owners, system administrators and HR staff must agree on who needs which document, because availability only works when the right people can reach the right procedure at the moment they need it.

Security official: Confirms which procedures are in force, approves the document set and decides who receives each part.
Procedure owners: Named staff for each area, such as backups, access reviews or incident response, who confirm that their procedures match how work is actually done.
System administrators: Confirm that the people who run the systems can open the runbooks and configuration documentation they depend on.
HR: Handles workforce communication, so new hires and role changes trigger access to the relevant documentation and removal when roles end.
Access owners: Confirm the role-to-document mapping against current job functions.

Before any outside party starts work, ask your team to write down the list of roles and the documents each role must reach, because that list becomes the basis for every access decision that follows.

Questions buyers ask about availability before hiring help

Can a small practice make its Security Rule documentation available in-house?

Yes, in most cases a small practice can make documentation available without outside help, provided the people who run each procedure can reach the current version when they need it. The rule asks that documentation be available to those responsible for carrying out the procedures it describes, not that it be published widely or stored in a particular product. The practical work is deciding who those people are, giving them access, and confirming they can find the right version. A practice with a few staff can often do this with a shared, access-controlled location and a short list of owners. Outside help becomes useful when the practice lacks the time or skills to design the access model and the review routine.

What does the work ask of the security official and administrators?

The security official and administrators must decide which documents belong to which roles, confirm that each role can read the documents that describe its procedures, and remove access that no longer fits. They also need to check that the documents stay current, because availability is weak if staff hold an outdated copy. This work is ongoing rather than a one-time task. It touches onboarding, role changes and departures, so it should be tied to existing access management and workforce processes. The security official owns the outcome; administrators usually carry out the account changes.

How long does setting up availability take, and what drives it?

The duration depends on the scope agreed in writing before work starts, not on a fixed number. The main drivers are how many procedures and roles exist, how many systems hold documentation today, whether access rules already exist in those systems, and how much review is needed to confirm that each role can reach what it needs. An organization with few documents and clear roles needs far less time than one with scattered policies across email, shared drives and personal folders. Ask any partner to show the scope, deliverables and milestones in writing, and to state which parts depend on your own staff's availability.

What can an implementation partner take off the team's plate?

A partner can prepare the document structure, set up a documentation platform hosted in your own infrastructure, configure roles and permissions, migrate existing documents and test that the right people can reach them. DeployOpen plans, implements, customizes, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own environment, and it can prepare the systems and evidence for a compliance assessment. A partner does not decide your risk posture, sign off on procedures as adequate, or take ownership of the security official role. Those remain with your organization. Confirm the exact split of tasks in the written scope.

Is a wiki or shared drive enough to make documentation available?

A wiki or shared drive can be enough if it gives the right people access, keeps a clear version history and lets staff find the current procedure quickly. The rule does not name a tool, so the question is whether the chosen system supports the controls your organization needs. Version history matters because it shows what changed, when and by whom, which also supports the updates requirement. Open-source options such as XWiki keep every change under version control and let users compare versions and roll back. BookStack assigns abilities through roles that can be overridden at the shelf, book, chapter or page level. Confirm with each vendor that these features work as you need them in your own deployment.

What can a third-party assessment show about availability, and what can it not show?

A third-party assessment can test whether documentation is reachable by the right roles, whether access matches the stated roles, and whether staff can locate current versions. It can review samples and interview staff to see whether procedures are known in practice. It cannot prove that availability has been maintained every day between reviews, and it cannot make your organization compliant. HHS states that no Security Rule standard requires certification and that it does not recognize private certifications, so any report is evidence for your own review, not a HIPAA certificate. Only the organization decides its compliance position, and an assessor offers an independent view of the evidence it examines.

How is availability evidence kept current between audits?

Keep current by building availability checks into routine operations rather than waiting for an audit. Practical steps include reviewing role-to-document access on a set schedule, linking account changes for new hires and departures to documentation access, and logging edits and access changes where the platform supports it. Periodic review of documentation for environmental or operational changes also keeps availability meaningful, because a current document nobody can find still fails the purpose. Ask any partner whether ongoing support, upgrades and testing are included, or offered as a retainer, and what evidence they will hand over at each review.

How DeployOpen prepares availability evidence for your team

DeployOpen treats 164.316(b)(2)(ii) as an operating requirement: the people who run ePHI systems must be able to reach the current procedures at the moment they need them. We set up the documentation platform inside your own infrastructure, populate it with your policies and procedures, and hand over the access model and version history your assessors will ask to see.

How we scope

Engagements are fixed-scope, with the documentation platform, user groups and procedure sets agreed in writing before work starts.
The written scope lists which Security Rule procedures are in the documentation set and which teams must be able to reach each one.
Scope also records where the platform runs, who administers it and which retention and backup duties your organization keeps.

How we build

We deploy a self-hosted wiki or documentation platform in your cloud account, data center or air-gapped network.
Role-based permissions are configured so workforce members responsible for each procedure can read it and only approvers can change it.
Version control and change history are enabled so every revision records what changed, when and by whom.

How we hand over

You receive a map of each procedure, its owner, the roles with access and the location of the approved copy.
Access tests are documented, showing that each named role can open the procedures it needs and no unauthorized role can edit them.
Administrator runbooks cover user onboarding, offboarding, backup and restore so your team can run the platform after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, sized to your written scope.
Periodic access reviews can be scheduled to confirm that role assignments still match current workforce responsibilities.
Your organization owns its controls and its final determination of compliance. An independent assessor, not DeployOpen, issues any report or attestation.