HIPAAmart

Research brief · 12 min read

What Evidence Should a Small Healthcare Organization Gather Before a HIPAA Risk Analysis?

An evidence map for organizing systems, data flows, people, vendors, safeguards, incidents, and resilience before a documented risk analysis. This is HIPAAmart editorial guidance, not a legal determination.

Reviewed August 2026

Definition

A useful risk analysis starts with an accurate view of the organization’s environment: where electronic protected health information is created, received, maintained, or transmitted; which threats and vulnerabilities matter; and how likely and consequential harm may be. This brief maps the evidence an organization can assemble before analysis. The map is HIPAAmart’s synthesis of HHS risk-analysis and Security Rule guidance and NIST SP 800-66 Rev. 2; it is not an HHS or NIST checklist, certification, or safe harbor.

In practice

  • A two-location practice maps its scheduling, EHR, billing, email, backup, identity, and support paths, then links each path to an owner and the evidence available for the risk discussion.
  • A business associate adds subcontractors, support access, logging, retention, incident notice, and exit controls to the service boundary instead of treating the signed BAA as the whole review.
  • A team records that a restore test was not available, preserves the date and owner of the gap, and treats the missing evidence as a question for the risk analysis rather than inventing a test result.

Who this applies to

  • Small healthcare practices and other covered entities preparing a Security Rule risk analysis
  • Business associates and subcontractors documenting the ePHI environment they support
  • Privacy, security, IT, compliance, and operations leads coordinating the evidence-gathering step
  • External advisors who need a neutral starting map before conducting a client-specific review

What the rule asks for

  • Scope and organization context: record the services, locations, workforce, systems, business processes, and responsibilities in the review.
  • ePHI inventory and data flows: identify where ePHI is created, received, maintained, or transmitted, including paper-to-digital and interface paths.
  • Systems and assets: list applications, devices, networks, cloud services, storage, integrations, administrative consoles, and dependencies that can affect ePHI confidentiality, integrity, or availability.
  • People and access: connect workforce roles, privileged accounts, service accounts, vendors, authentication, provisioning, termination, and access-review evidence to the systems in scope.
  • Safeguards and operating evidence: gather relevant administrative, physical, and technical policies, configurations, logs, training records, facility practices, and control-test results.
  • Third parties and shared responsibility: include business associates, subcontractors, hosting providers, support channels, data processors, contracts, and the boundaries of each party’s responsibilities.
  • Threats, vulnerabilities, and incidents: preserve known weaknesses, threat scenarios, security events, complaints, investigations, remediation records, and lessons from exercises without adding identifying health information.
  • Resilience and change: include backups, restoration tests, contingency plans, emergency operations, major changes, acquisitions, new interfaces, and material vendor or workflow changes.

How teams put it into practice

  • Start with a scope statement and a named owner. Write down the systems, workflows, locations, and third parties included and excluded, along with the reason for each boundary.
  • Build the ePHI data-flow and asset inventory from how work actually happens. Reconcile interviews, system records, contracts, diagrams, access lists, and configuration evidence instead of relying on one source.
  • Attach evidence to each material system and workflow with an owner, date, source, and status. A missing artifact is a review finding to investigate, not proof that a safeguard is absent.
  • Use the inventory to identify plausible threats and vulnerabilities, then document likelihood and impact using a repeatable method appropriate to the organization. Evidence collection supplies inputs; it does not replace the analysis.
  • Record decisions, assumptions, compensating measures, and follow-up work. Revisit the map when the environment, threats, technology, workforce, or business relationships materially change.
  • Treat this sequence as editorial guidance for preparation. HHS describes the purpose and expectations of risk analysis, while NIST provides implementation-oriented context; neither source turns this map into a legal conclusion about a specific organization.

Common mistakes

  • Calling a completed checklist, policy folder, or vendor questionnaire a risk analysis without documenting threats, vulnerabilities, likelihood, and impact.
  • Starting with controls and missing the data flows, business processes, identities, or third parties that determine what is actually at risk.
  • Treating the HHS Security Risk Assessment Tool or NIST SP 800-66 Rev. 2 as a regulator-issued certification or as a substitute for organization-specific judgment.
  • Collecting screenshots or exports without recording the system, scope, owner, date, and question the evidence is meant to answer.
  • Including patient names, record numbers, clinical details, or other PHI in a research worksheet, public form, or published example.
  • Assuming a BAA transfers all security responsibility or that a vendor’s assurance document covers the covered entity’s own configuration and workforce practices.
  • Publishing a list as exhaustive or legally sufficient when it is only a bounded editorial synthesis for a small-organization starting point.

Questions that come up

Is this HHS’s required list of risk-analysis evidence?

No. HHS describes the purpose and general expectations of a risk analysis, and NIST SP 800-66 Rev. 2 provides implementation guidance. The categories on this page are HIPAAmart’s editorial synthesis for organizing preparation; they are not an official checklist or exhaustive legal standard.

Does gathering these items prove that an organization is HIPAA compliant?

No. Evidence gathering supports a risk analysis but does not itself establish compliance, eliminate risk, or provide an audit opinion. The organization must evaluate its own facts, document decisions, and obtain appropriate professional advice where needed.

Should a research or preparation worksheet contain PHI?

No. This brief uses no PHI, survey responses, customer records, or product-use dataset. Use de-identified, aggregated descriptions when an example is needed, and do not place patient names, record numbers, or clinical details in a public form or publication.

How should NIST SP 800-66 Rev. 2 be used here?

Use it as implementation-oriented context and a way to organize questions around the Security Rule. NIST is not a regulator, and this brief does not treat its mappings or activities as a certification, mandatory checklist, or replacement for the applicable regulation.

References