164.308(a)(8) Evaluation: requirements and evidence

What 164.308(a)(8) evaluation asks for and why it is the closest thing to an audit

If you lead compliance for a covered entity or business associate, the question 164.308(a)(8) puts to you is simple: can you show that the Security Rule is being checked, not just written down? The standard requires a periodic technical and nontechnical evaluation of how well your security policies and procedures meet the rule. The first evaluation is measured against the standards the rule sets. After that, the evaluation must be repeated whenever an environmental or operational change affects the security of electronic protected health information, such as a new hosting platform, a merger, a major application change or a new class of threat. The standard has no separate implementation specifications, so its weight comes from how you design and run it.

The risk this standard addresses is drift. Controls that were accurate when written can stop matching the systems they describe: an access review gets skipped, a backup job changes owner, or a patch cycle slips after a migration. Nobody notices until an incident or an OCR inquiry exposes the gap. Evaluation is the mechanism that catches drift early. In practice, three things make it hard. First, many organizations never define the measurements against which each standard is judged, so the evaluation becomes an opinion. Second, there is no repeat cycle, so it happens once after a project and then lapses. Third, results are not written down in a form that shows what was tested, what was found and what was fixed.

Before you schedule anything, decide whether the evaluation will be internal or external, and document that choice. Confirm with your security official which evaluation methods, sources of evidence and pass criteria you will use for each standard, and confirm that the change triggers that would prompt a new evaluation are written into your change management process. HHS notes that an evaluation may be performed by an outside organization, but that a private certification does not prevent HHS from later finding a violation, so an external review informs your position and does not replace your own record. The eCFR text of 45 CFR 164.308(8)) is the starting point for confirming the wording your program must meet.

Which systems, teams and vendors an HIPAA security evaluation must cover

The 164.308(a)(8) evaluation has no fixed boundary in the rule, so scope comes from where ePHI lives and how that environment changes. The cards below cover the decisions that set that scope, from data stores and teams to vendors and the events that should trigger a fresh evaluation. A covered entity and a business associate each scope the evaluation to their own ePHI environment.

Every system and store holding ePHI

Start with an inventory of every application, database, backup set, endpoint, email account and file share that creates, receives, maintains or transmits ePHI. The evaluation must test whether the policies and procedures meet the Security Rule for each of these locations, so an unlisted store is an unevaluated risk. Ask who owns each location and when the inventory was last reconciled against the risk analysis. Missing inventory entries are the most common scoping gap.

Workforce roles and their processes

The evaluation reaches the people who run ePHI systems as well as the technology. Cover administrators, help desk staff, clinicians, billing teams, contractors and management, and the processes they follow for access requests, password resets, onboarding, offboarding and incident reporting. Check whether each role's documented procedure matches what staff actually do, since an evaluation that reads only the written policy will miss drift.

Third parties that host or access ePHI

Cloud providers, managed IT firms, billing companies, clearinghouses and software vendors that host or access ePHI fall inside the evaluation's reach for the portion of the environment they touch. Confirm which vendors have business associate agreements, which subcontractors they use, and whether their security evidence is current. A covered entity should not assume a vendor's own certificate or report answers the evaluation question for its own ePHI.

New systems and infrastructure moves

Adding a new application, moving workloads to a different cloud account or data center, or replacing an identity system changes where ePHI sits and how it is protected. Treat each such project as a trigger for re-evaluating the affected safeguards, not as an IT change ticket alone. Ask whether the change record links to the risk analysis and whether the responsible security official signed off on the new configuration.

Mergers, acquisitions and new vendors

A merger or acquisition brings in systems, staff and vendor contracts that the existing evaluation never examined. Onboarding a new vendor that will handle ePHI has the same effect on a smaller scale. Require the acquired or new environment to be inventoried, its business associate arrangements reviewed, and its access and training practices compared against the current policies before it connects to the ePHI environment.

Significant incidents and failed controls

A security incident, a ransomware event, a lost device or a failed restore test shows that some safeguard did not work as documented. The rule's wording on evaluation anticipates re-evaluation after operational changes affecting ePHI security, and an incident is usually the clearest example. Ask whether the post-incident review updates the evaluation scope, the risk analysis and the affected policies, and whether the findings are dated and retained with the evaluation record.

How an assessor tests the HIPAA evaluation requirement

This table follows the questions an assessor asks about 164.308(a)(8) Evaluation, from the choice of internal or external evaluation through to repeat evaluations after change. Each row shows the evidence that answers the question and the finding that usually appears when it does not. The main takeaway is that the rule sets no checklist, so an assessor judges whether the entity can show a documented, repeated and acted-on evaluation.

Assessor question	Evidence the assessor expects	Common finding
Did the entity decide between internal and external evaluation, and why?	A written decision record that names who performs the evaluation, the reasons for the choice, and the qualifications of any outside firm.	No record of the decision, or an outside firm engaged without a stated scope or reason.
Were standards and measurements defined for every standard and specification?	A written evaluation method that maps each Security Rule standard and implementation specification to a test, measure or review question.	Evaluation criteria cover only a few safeguards, or the method simply restates the policy text.
Was the evaluation performed and its results documented?	Dated evaluation report with scope, the systems and processes examined, testing performed, and findings for each area.	The evaluation only restates policy, has no dated results, or does not cover systems that hold ePHI.
Did the results lead to tracked remediation?	Findings register with owners, due dates, risk decisions and closure evidence linked to the risk management plan.	Findings are recorded but never assigned, or closed without evidence that the gap was fixed.
Were evaluations repeated periodically?	A schedule or policy setting the cadence, plus prior evaluation reports showing that the schedule was followed.	No second evaluation exists, or the schedule is written but the last evaluation is well past it.
Did an evaluation follow environmental or operational changes?	Change records for major system, network, vendor or organizational changes, each paired with a targeted re-evaluation.	The last evaluation predates a major system change, such as a cloud migration or new EHR, and no follow-up was performed.
Who performed the evaluation and can they show the work?	Named evaluators with documented method, working papers and sign-off by the security official or leadership.	Evaluator cannot be identified, or working papers are missing so the result cannot be traced.

How to run an evaluation that satisfies 164.308(a)(8)

The sequence below follows the key activities NIST SP 800-66 Rev. 2 describes for this standard, moving from choosing an internal or external evaluator, through defined measurements and documented results, to a repeat cycle that also responds to environmental and operational change. NIST SP 800-66 is informational guidance, not a legally binding requirement, so the organization still decides how to meet the standard.

Decide internal or external evaluation
The security official, with compliance and executive sponsors, decides whether the evaluation will be run by internal staff, an external organization, or a mix of both. HHS FAQ 2003 confirms that either route is possible, and it notes that private certifications do not bind HHS. Weigh the independence needed for the findings, the skills available in-house, and the systems in scope. The output is a short decision memo that names the evaluator, the reason for the choice, and who signs off on the results. The step is done when the memo is approved and filed with the Security Rule documentation.
Define standards and measurements
Before any testing begins, the evaluator writes the criteria used to review every standard and implementation specification in the Security Rule, including the addressable ones and the documentation requirements. Each criterion needs a measurement, such as a policy that exists and is approved, a control that is configured as described, or a log that is reviewed on a set schedule, along with the evidence that would show it. Because the evaluation is only as credible as its measurements, these must be fixed before the work starts, not adjusted to fit what is found. The output is a measurement workbook that maps each requirement to its test, evidence source and pass or fail rule, signed off by the security official.
Perform the technical and nontechnical evaluation
The evaluator tests the workbook against the environment as it actually operates. The technical side examines configurations, access rights, vulnerability data and logs, and the nontechnical side reviews policies, procedures, training records, staff interviews and physical arrangements. Open-source tooling such as Wazuh vulnerability detection or Fleet host software inventory can produce some of this evidence, but the evaluator still judges whether each result meets the measurement. Record the test date, the person who ran it and the artifacts reviewed. The step closes when every row in the workbook has a result and its supporting evidence.
Document results in an evaluation report
The evaluator writes a report that states the scope, the measurements used, the evidence reviewed, each finding and the gaps against the Security Rule. Each gap should be stated plainly, with the requirement it affects and whether it concerns a required or addressable specification. Where an addressable specification is not implemented, the report should show the documented reasoning and any equivalent alternative measure, as 45 CFR 164.306(d) requires. The output is a dated evaluation report approved by the security official. Confirm with counsel how the report is labeled and stored, since it may be requested during an OCR investigation.
Feed findings into risk management
Each finding moves into a findings register that records the owner, the affected systems, the planned fix and the status. The risk management process under 164.308(a)(1)(ii)(B) then decides how each gap is reduced to a reasonable and appropriate level, and the register shows the link between the evaluation and the measures taken. Findings that are closed should carry the evidence that closed them, so the next evaluation can test the fix. The step is complete when every finding has an owner, a disposition and a linked risk decision.
Set the repeat cycle and change triggers
Schedule the next evaluation and write down the events that force an earlier one, such as a new electronic health record, a change of hosting environment, a merger, a material security incident, or a new threat that affects the organization. The standard calls for periodic evaluation and for re-evaluation after environmental or operational changes, so the schedule must reflect the organization's own risk profile. The output is an evaluation calendar and a written list of triggers approved by the security official. Ask the evaluator to confirm that the schedule can be met with the staff and tooling available.

Evidence that passes an evaluation review

An evaluation under 164.308(a)(8) is only as credible as the paper behind it. The cards below cover the artifacts an OCR investigator, auditor or internal reviewer would expect to find, from the plan that set the method to the approval that closes the cycle. Each one should trace back to the same standards and specifications so the evaluation can be followed from start to finish.

Evaluation plan and measurements

The plan states whether the evaluation is internal or external, which standards and specifications it covers, and the measurements used to judge each one. NIST SP 800-66 Rev. 2 expects the organization to decide the evaluation approach and develop standards and measurements before testing starts. Check that the plan names who performs each review, the evidence sources they will use, and how the plan will be repeated after environmental or operational changes. A plan written after the evaluation is hard to defend.

Evaluation report mapped to each standard

The report records the result for every standard and implementation specification in 45 CFR 164.308 through 164.316, not only the ones that changed. Each entry should state what was reviewed, what was found, and whether the control meets the rule as implemented. Reviewers look for gaps in coverage, such as physical or technical safeguards left out because they sit in a different section. Ask the assessor to confirm that addressable specifications have a documented decision.

Workpapers and test results

Workpapers hold the raw proof behind each conclusion: configuration exports, sampled access reviews, restore test logs and interview notes. Store them with dates, the name of the person who collected each item, and a reference to the report line they support. For technical checks, scanner output and endpoint inventories can serve as inputs, but the reviewer still has to explain what the output shows. Confirm that retention and access to workpapers follow the organization's documentation policy.

Findings and remediation register

The register lists each finding with its severity, the standard it affects, a named owner, a target date and the evidence that will close it. Findings that remain open at the end of the evaluation should carry a documented reason and a compensating measure where one is reasonable and appropriate. Reviewers check whether the same finding appears in the next evaluation without progress. Tie each entry back to the risk management plan so that remediation work is visible in both places.

Change log tied to evaluation triggers

The rule requires re-evaluation in response to environmental or operational changes that affect ePHI security. A change log should record each trigger, such as a new cloud region, a migration to a new identity provider, an acquisition or a material software upgrade, along with the evaluation it prompted. Gaps between a change and its review are a common finding. Ask the team to confirm that change tickets link to the evaluation record, so the trigger can be traced without a manual search.

Security official approval and tooling inputs

The security official signs off on the evaluation report, accepts or rejects each finding and records the decision date. Tools can feed this step without replacing it. CISO Assistant (AGPL-3.0-only) can run assessments against many frameworks and retain their results, Wazuh (GPL-2.0-only) correlates each agent's software inventory with its vulnerability content, and Fleet (MIT) matches installed software on enrolled hosts against sources including the NVD, OVAL definitions and OSV. Confirm each tool's license terms with counsel before deploying it.

What a HIPAA security evaluation costs in money and staff time

This table compares the cost components of a 164.308(a)(8) evaluation, who is paid for each, and whether the cost is one-time or recurring. No fee figures are supplied here, so use the drivers and the quote checklist to compare written, scoped proposals.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it
Internal staff time to define measurements and standards	Your security official, compliance lead and system owners	One-time to set up, then recurring as measurements change	Number of systems holding ePHI and how mature existing measurements are
Internal staff time to run the evaluation and document results	Your security and compliance staff	Recurring, each evaluation cycle	Scope of the evaluation and how many policies and procedures are reviewed
External evaluator fees	The outside firm that performs the evaluation	Recurring if used each cycle; ask whether the fee is one-time per engagement	Scope, number of sites, and whether the firm also tests technical controls
Tooling and hosting for open-source platforms	Your infrastructure team, or a partner for setup; no license fee for the named tools	Recurring hosting and maintenance; one-time setup	Hosting footprint, data volume, and the staff needed to keep tools patched and configured
Remediation of findings	Your system owners, IT staff or a delivery partner	Recurring, driven by the number and severity of findings	Age of existing controls and how quickly gaps are fixed after each evaluation
Technical testing, if included in the evaluation	A testing provider, such as a vulnerability assessment or penetration test team	Recurring if repeated on a schedule	Number of internet-facing and internal systems, and rules of engagement
Auditor or assessor effort when an outside party reviews results	The independent assessor, paid by your organization	Recurring if you request an external review each cycle	Volume of evidence, number of business associates in scope, and change frequency

In-house, partner or assessor: who evaluates what

The covered entity or business associate owns the evaluation. Under 164.308(a)(8), the organization must decide how far its policies and procedures meet the Security Rule, and that judgment cannot be handed to anyone else. The security official and the people who run the systems set the measurements, review the results, decide what to fix, and document the outcome. The first evaluation is based on the standards the organization has implemented, and later evaluations respond to environmental or operational changes such as a new cloud region, a merger or a new clinical application.

Deciding internal or external work: NIST SP 800-66 Rev. 2 treats the choice between an internal and an external evaluation as a first key activity, and the organization makes it.
Setting measurements: The team defines the standards and specifications each review covers and what passing looks like for each.
Running the review: Staff walk through access lists, logs, backup restores and training records against the Security Rule.
Documenting and acting: Results, findings and remediation decisions are recorded and retained with the policies they test.
Usually outsourced: Little of the decision-making. Some organizations hire a consultant to draft checklists or facilitate the review, but the organization signs off on the results.

Check that your security official can name the measurements, the reviewer and the date of the last evaluation without consulting an outside party.

Where HIPAA evaluations fall short and how to close each gap

The evaluation standard in 45 CFR 164.308(a)(8) is short, but OCR and reviewers look for specific habits behind it. The gaps below recur in organizations that run an evaluation on paper but cannot show that it tested the safeguards, fed results back into risk management, or was owned by someone accountable.

Restating policy instead of testing controls

An evaluation that re-reads the written policies and confirms they exist does not show whether safeguards work. Under 164.308(a)(8), the question is how far policies and procedures meet the Security Rule in practice. Check that each control has a test step: sample access reviews, pull backup restore records, confirm that audit log reviews happened on schedule. A useful test asks for an artifact produced by the control, not a statement that it exists.

No measurements set before testing

Without defined criteria agreed in advance, an evaluation tends to conclude that everything is fine. NIST SP 800-66 Rev. 2 lists developing standards and measurements for reviewing every standard and specification as a key step before the evaluation runs. Write the pass criteria for each safeguard, such as what counts as a timely termination or a complete log review, and record them in the evaluation plan so the results can be compared with the same yardstick each cycle.

No re-evaluation after major change

The standard expects evaluation again in response to environmental or operational changes that affect ePHI security. A new cloud region, a migration of the EHR, an acquisition, or a serious incident can make an earlier evaluation out of date. Keep a trigger list that names these events and assigns someone to decide, within a set period after each event, whether a targeted re-evaluation is needed. Record the decision even when the answer is no.

Findings that never reach risk management

An evaluation that produces findings with no link to the risk management plan under 164.308(a)(1)(ii)(B) leaves the gaps open. Each finding should be logged with an owner, a decision (fix, accept, or transfer), and a due date, then carried into the risk register. Reviewers often ask for the trail from a finding to a closed item, so confirm that your tracker keeps that history and that the next evaluation checks whether earlier findings were closed.

No named owner or approval

An evaluation with no accountable owner has no one who can commit resources to fix findings or sign off on residual risk. The Security Rule places security responsibility on a named official under 164.308(a)(2), and that person or a delegate should approve the evaluation scope, methods, and results. Document who ran the evaluation, who reviewed it, and who accepted the findings. If an outside firm performs the work, the internal owner still needs to review and adopt the results.

Treating a private certificate as proof

HHS states that it does not endorse or recognize private certifications, and that a certificate does not stop HHS from later finding a violation. An external firm can perform the evaluation, but its report is evidence of work done, not a HIPAA certificate. Ask any provider what the report covers, which safeguards were tested and how, and whether the organization retains the findings and the evidence behind them.

Questions buyers ask about HIPAA evaluation cost, effort and outside help

How much effort does a HIPAA security evaluation take, and what drives it?

The rule does not set an hour count or a fixed duration, so effort depends on the size and complexity of the environment and how well existing documentation maps to the Security Rule. The main drivers are the number of systems that hold or touch ePHI, how many policies and procedures exist and how current they are, how many third parties host or process ePHI, and whether the organization already keeps evidence such as access reviews, training records and patch reports. NIST SP 800-66 Rev. 2 lists the activities involved: choosing an internal or external evaluation, setting measurements for each standard and specification, conducting the evaluation, and documenting results. Ask any provider to break its estimate down by those activities and by system count.

How often must a HIPAA security evaluation be repeated?

The current standard requires a periodic evaluation first against the rule, and then again in response to environmental or operational changes that affect ePHI security. The rule does not set a fixed interval. The January 2025 proposed rule would add a compliance audit requirement at least once every 12 months, but that proposal is not final as of October 2026, and the latest Unified Agenda lists final action for July 2027. Until a final rule is published, decide the interval in your risk analysis and document why it is reasonable, and treat any annual cycle as a planning choice rather than a current legal requirement.

Can our own staff perform the HIPAA evaluation internally?

Yes. HHS FAQ 2003 says the evaluation can be performed internally or by an external organization. Internal staff know the environment, but they must be able to assess their own controls objectively, and the evaluation must cover every standard and implementation specification, not only the ones the team already trusts. Internal evaluators typically need documented criteria, access to system owners and evidence, and time that is protected from operational duties. Many organizations split the work: internal staff gather evidence and run the assessment, while an outside party reviews the method or the results.

What does an outside partner do for the HIPAA evaluation, and what does it not do?

An outside partner can plan the evaluation method, define measurements for each safeguard, collect and organize evidence, test technical controls, document gaps and help prioritize remediation. DeployOpen works this way for its clients: it prepares systems, controls and evidence inside the client's own infrastructure. The organization remains responsible for its controls and for its own Security Rule compliance, and it must make the decisions about risk acceptance. No outside partner can issue a HIPAA certificate or make a finding that binds HHS. Only an independent assessor can issue a formal report, and HIPAA has no certification that replaces OCR's review. Confirm the exact deliverables in the written scope before work starts.

Does a third-party HIPAA certificate satisfy the evaluation standard?

No. HHS FAQ 2003 states that it does not endorse or recognize private certifications, and that such certifications do not prevent HHS from later finding a violation. No Security Rule standard requires certification. An external evaluation can support your compliance work, and it may give your leadership and business partners an independent view, but the covered entity or business associate still owns the evaluation and its results. Treat any document that claims to certify HIPAA compliance as a marketing claim to verify, not as evidence that satisfies 164.308(a)(8).

What do we need from our staff to run the evaluation?

The evaluation needs named owners for each system and process that handles ePHI, a security official who accepts the results, and access to the people who run daily operations, such as IT administrators, clinical system owners, HR for workforce changes and facilities for physical controls. Staff must provide current policies, procedures, access lists, training records, backup and restore results, incident logs and vendor contracts. Expect to set aside time for interviews, walkthroughs and reviewing draft findings. Confirm in writing which roles are needed, how many hours of staff time the scope assumes, and who approves the final report.

What should we ask for in a written quote for an evaluation?

Ask the provider to state the scope in writing, including which systems, facilities, vendors and Security Rule standards are covered, and which are excluded. Request the deliverables by name, such as the methodology, measurement criteria, evidence index, findings list and remediation plan, and whether any report is intended for an independent assessor. Ask which costs are one-time, such as the initial evaluation, and which recur, such as re-evaluations after environmental changes or an annual cycle if you choose one. Ask who performs each activity, what staff time you must supply, what happens if scope changes, and what the provider will not do, including issuing any certificate or attestation.

What drives the cost of an evaluation up or down?

Cost is driven by scope, the number of systems and locations, the number of third parties that touch ePHI, the maturity of existing documentation and the amount of technical testing required. Work that is mostly document review costs less than work that requires configuration checks, log review or testing of backup restores. Internal labor is a cost too, even when no invoice is issued. Recurring costs come from re-evaluations after major changes, such as a new EHR, a cloud migration or a merger. The risk analysis that OCR expects should set the depth of evaluation, so a clear risk analysis usually makes scoping and pricing easier to compare.

How DeployOpen prepares systems and evidence for an HIPAA evaluation

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the systems and records behind your Security Rule evaluation are ready for review. We prepare the evidence and the measurement baseline, while your organization owns its policies, its evaluation decisions and the conclusions it draws from them.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names which ePHI systems, platforms and Security Rule standards the evaluation will cover.
We agree with you whether the evaluation runs internally, externally or as a mix, since that choice stays with your organization.

How we build

We set up the evaluation measurements and review criteria for each Security Rule standard and specification in scope.
We configure vulnerability detection and software inventory on the systems that hold ePHI, so evaluation findings draw on current data.
We test the platforms against the agreed criteria and record gaps against the Security Rule for your review and remediation.

How we hand over

You receive documented evaluation results, including the criteria used, the evidence reviewed and the gaps identified.
Runbooks explain how to repeat the evaluation periodically and after environmental or operational changes to ePHI systems.
Evaluation records are delivered to your own repositories, so your organization keeps retention and access control over them.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement.
Retainers can cover repeat evaluations, platform updates and changes to ePHI systems that trigger a new review.
Independent assessors and auditors remain the only parties who issue assessment reports, since DeployOpen does not certify HIPAA compliance.