Start HIPAA Security Compliance With a Documented Risk Analysis

The direct answer: begin with a HIPAA security risk analysis

Conduct and document a HIPAA security risk analysis. For the HIPAA Security Rule, that is the first step toward identifying and implementing appropriate safeguards—not buying software, selecting a cybersecurity framework, or completing a generic checklist.

The governing requirement appears at 45 C.F.R. § 164.308(a)(1)(ii)(A). It calls for an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information, or ePHI. The analysis must address all ePHI the organization creates, receives, maintains, or transmits and must be documented. HHS describes risk analysis as the first step in identifying and implementing safeguards that comply with the Security Rule. HHS explains the governing risk-analysis requirement and its role in the Security Management Process.

This answer is specific to the HIPAA Security Rule. Other laws, contracts, regulatory programs, and cybersecurity frameworks may use terms such as “security rule,” “risk assessment,” or “security assessment” differently. Those obligations may apply alongside HIPAA, but they do not change the HIPAA-specific starting point addressed here.

The analysis concerns risks to three properties of ePHI:

Completing the analysis begins the Security Management Process, but it does not establish full compliance by itself. The organization must use the findings to manage identified risks, select and implement reasonable and appropriate safeguards, document decisions, and continue evaluating its risk environment.

In practical terms, the sequence is:

1. Define the scope and locate ePHI.
2. Identify relevant threats and vulnerabilities.
3. Evaluate existing safeguards, likelihood, and potential impact.
4. Document evidence, assumptions, and conclusions.
5. Prioritize risks and decide how they will be treated.
6. Implement and verify reasonable safeguards.
7. Review the analysis as systems, vendors, operations, and risks change.

The first step is analytical, but it is not merely theoretical. Its purpose is to give the organization a defensible, evidence-based foundation for action.

Who must perform the analysis—and what information the Security Rule covers

The HIPAA Security Rule applies to covered entities and their business associates. Covered entities generally include health plans, healthcare clearinghouses, and healthcare providers that conduct specified healthcare transactions electronically. The Security Rule protects PHI maintained or transmitted electronically; it does not apply in the same way to PHI communicated only verbally or maintained only on paper. The HHS Security Rule summary describes who is covered, what information is protected, and the required safeguard categories.

That distinction matters when defining the analysis:

• A patient record stored in an electronic health record is ePHI.
• The same information in an email, electronic claim, spreadsheet, cloud backup, or mobile application may also be ePHI.
• Information existing only in a paper chart is not ePHI for Security Rule purposes.
• A verbal conversation is not itself electronic merely because it contains PHI.
• A recording or electronic transcription of that conversation may be ePHI if it otherwise meets the definition of PHI.

This does not mean an organization may disregard paper or verbal PHI. The HIPAA Privacy Rule and other requirements may still govern those forms of information. It means that the Security Rule risk analysis has an ePHI-specific scope; a broader privacy assessment may be needed to address non-electronic information and other obligations.

The three protection objectives should be considered in operational terms. Confidentiality can be affected by an outside attacker, but also by excessive employee permissions, a misdirected email, shared credentials, or poorly controlled vendor access. Integrity can be affected by unauthorized changes, data corruption, malware, or defective system interfaces. Availability can be affected by ransomware, hardware failure, damaged facilities, lost credentials, or backups that cannot be restored.

Small practices and smaller business associates are not categorically excused from conducting the analysis. At the same time, the Security Rule is scalable and technology-neutral: implementation may reflect an entity’s size, complexity, capabilities, technical infrastructure, resources, environment, and risks. It does not require every regulated organization to use identical technologies or controls. HHS explains that regulated entities must use reasonable and appropriate safeguards while accounting for their circumstances.

That flexibility affects how the work is performed, not whether all relevant ePHI is considered. A small practice may use a simpler inventory, interview process, and risk register than a national health system. It still needs an accurate understanding of where its ePHI exists, how it moves, and what could compromise it. Scaling the method should not mean arbitrarily shrinking the scope.

The first practical task inside the analysis: define the scope and locate every source of ePHI

There are two related starting points:

• The regulatory compliance process begins with a risk analysis.
• A practical way to begin that analysis is to define its scope and locate all ePHI.

The scope must account for all ePHI the organization creates, receives, maintains, or transmits. That is broader than listing the primary clinical system. The objective is to understand the people, technologies, locations, services, and workflows through which ePHI passes.

A practical inventory may include:

• Electronic health record and practice-management platforms
• Billing, coding, claims, scheduling, and patient-communication tools
• Servers, databases, network storage, and file shares
• Desktop computers, laptops, and workstations
• Smartphones, tablets, and other mobile devices
• Removable media and portable storage
• Email, messaging, electronic fax, and document-exchange systems
• Cloud applications and hosted infrastructure
• Backups, archives, replicas, and disaster-recovery environments
• Connected clinical or diagnostic equipment
• Remote-access services and home-working equipment
• Offices, clinics, data rooms, and storage or equipment areas
• Employees, contractors, administrators, clinicians, and other user groups
• Business associates, subcontractors, hosted platforms, and other vendors that interact with ePHI

These examples are a practical scoping aid, not a regulator-prescribed universal checklist. Some may not apply to a particular organization, while specialized systems or workflows not listed here may be essential to another.

The inventory should cover data flows as well as assets. Map how ePHI:

1. Enters the organization.
2. Moves between people, applications, devices, and locations.
3. Is stored, copied, exported, synchronized, archived, or backed up.
4. Is accessed remotely.
5. Is transmitted to health plans, laboratories, pharmacies, consultants, and other outside parties.
6. Becomes accessible to vendors and business associates.
7. Is deleted, destroyed, or otherwise disposed of at the end of its applicable retention period.

Data-flow mapping often identifies exposures that a conventional asset list misses. An organization might record its EHR yet overlook downloaded reports on a manager’s laptop, claims attachments sent by email, files temporarily stored by an integration provider, or backups administered through a cloud service.

Vendor connections require particular attention. Identify what ePHI a vendor can access, how access occurs, whether access is persistent or temporary, which accounts or interfaces enable it, and where the information is stored or processed. Relevant hosted-service and subcontractor dependencies should also be considered to the extent they affect the organization’s ePHI risk.

Remote access can create similar blind spots. Depending on the environment, the scope may include virtual private networks, remote-desktop services, browser-based portals, personal or organization-owned mobile devices, home-working equipment, and support channels used by vendors or internal administrators.

Do not treat the EHR as the complete scope. ePHI may also exist in email, billing tools, spreadsheets, scanned documents, exports, mobile devices, connected equipment, backups, third-party systems, and discarded hardware. Third-party implementation guidance illustrates how organizations can map systems, personnel, media, vendors, and internal and external data flows rather than reviewing only the principal record system. Vanta provides one practical, non-regulatory example of this scoping approach.

A useful scope statement identifies the organizational units, locations, technologies, information categories, workflows, and external connections included in the analysis. If an item is excluded, record the reason. That makes omissions visible and allows assumptions to be challenged before they become embedded in the conclusions.

How to identify and evaluate risks without assuming a mandated formula

Once the ePHI environment is reasonably understood, identify threats that could affect it. Relevant threats vary by organization, but examples include:

• Unauthorized internal or external access
• Phishing and stolen credentials
• Ransomware and other malicious software
• Device or media loss
• Accidental disclosure, alteration, or deletion
• Human error and misconfiguration
• Insider misuse
• Software, hardware, power, or communications failure
• Vendor or supply-chain disruption
• Fire, flooding, severe weather, and other environmental events

A threat is not the same as a vulnerability. Credential theft, for example, is a threat; weak authentication and inadequate account monitoring are vulnerabilities that can make it more likely to cause harm.

Other possible vulnerabilities include:

• Excessive or outdated user permissions
• Shared accounts
• Unsupported software
• Missing, incomplete, or untested backups
• Inadequate device management
• Poorly secured server or equipment areas
• Weak change-management practices
• Incomplete incident-response procedures
• Uncontrolled exports of ePHI
• Poorly governed remote or vendor access
• Insufficient workforce training
• Missing monitoring or review processes

Next, review the administrative, physical, and technical safeguards already in place. Risks should not be evaluated as if no controls exist. Authentication, access restrictions, monitoring, backups, workforce procedures, and physical protections may reduce the likelihood of an event, its consequences, or both.

For each meaningful threat-and-vulnerability combination, consider:

• Likelihood: How reasonably likely is the event in the organization’s actual environment?
• Impact: If it occurred, how seriously could it affect ePHI confidentiality, integrity, or availability?
• Existing safeguards: Which controls reduce the risk, and what evidence indicates that they operate as intended?
• Residual concern: What risk remains after those safeguards are considered?
• Priority: How urgently does the organization need to respond?

HIPAA does not prescribe one universal methodology, software product, numerical matrix, or likelihood-times-impact formula. An organization may use qualitative labels, numerical scales, narrative judgments, or another consistent method suited to its circumstances. The important result is an accurate, thorough, supportable, and documented analysis—not adherence to a vendor’s preferred model. This commercial compliance guide summarizes several possible methods while recognizing that no single scoring approach is universally prescribed.

Consistency matters more than false precision. If the available evidence cannot support an exact probability, document a bounded judgment and its assumptions. For example, an organization might classify credential compromise as reasonably likely because remote access lacks strong authentication and phishing attempts are routinely observed. That explanation is more useful than an unsupported percentage.

A generic checklist can prompt useful questions, but copied answers do not establish that the organization investigated its own environment. The analysis should connect actual ePHI, systems, workflows, threats, vulnerabilities, safeguards, and potential consequences. A template is a starting structure, not a substitute for evidence and judgment.

What a useful documented risk analysis should show

Documentation is part of the required foundation of the analysis, not a presentation layer added after the substantive work is complete. HHS guidance states that the analysis must be documented, but it does not prescribe one universally sufficient report format or documentation package. HHS describes the required analysis as accurate, thorough, organization-wide in scope, and documented.

As a practical management approach—not a universal regulatory checklist—a documented analysis may include:

• The purpose and scope of the analysis
• The organizational units, locations, systems, and workflows considered
• The categories and locations of ePHI
• Relevant data flows and external connections
• The methodology and rating approach
• Participants, responsibilities, and information sources
• Identified threats and vulnerabilities
• Existing safeguards and evidence of their operation
• Likelihood and impact judgments
• Assumptions, limitations, and unresolved questions
• Resulting risk levels or priorities
• The reasoning supporting material conclusions

One organization may use a structured report and risk register. Another may combine inventories, diagrams, interview records, technical evidence, and a summary register. The relevant question is whether the collected documentation accurately and understandably reflects the work.

Record enough reasoning to make the analysis understandable and repeatable. A future reviewer should be able to determine why an issue was included, what evidence was considered, how existing safeguards affected the rating, and why the organization assigned a particular priority.

For each material risk, an optional management record can identify:

• The risk statement
• The affected ePHI, systems, workflows, or locations
• The responsible owner or accountable function
• The proposed treatment
• The priority
• A target date or follow-up milestone
• Current status
• Evidence needed to verify completion
• Any remaining risk requiring a documented management decision

Possible management treatments include mitigation, avoidance, transfer, and acceptance. These are planning concepts, not automatic HIPAA safe harbors. Calling a risk “accepted” does not by itself establish that the decision is reasonable. As a sound governance practice, acceptance should be informed, documented, authorized at an appropriate level, and reconsidered when relevant circumstances change.

Likewise, transferring certain financial or operational consequences through insurance or a contract does not necessarily reduce the underlying threat to ePHI. The record should distinguish between shifting some consequences and implementing safeguards that actually change likelihood or impact.

Questionnaires and automated tools can organize interviews, prompt evidence collection, and calculate ratings. They cannot replace organization-specific investigation. A completed form that overlooks a cloud environment, omits vendor access, or assumes that controls work without evidence does not become thorough merely because every field contains an answer.

The value of documentation is not its page count. It lies in showing that the organization understood its environment, evaluated relevant risks, and created a reasoned basis for action.

What comes next: turn findings into risk management and safeguards

Risk analysis and risk management are related but distinct. Risk analysis identifies and evaluates potential risks and vulnerabilities. Risk management uses those findings to select and implement measures that reduce risks and vulnerabilities to a reasonable and appropriate level. Both are parts of the Security Management Process. This HIPAA-focused explanation summarizes the relationship between the required analysis and the risk-management measures that follow.

Translate prioritized findings into a documented remediation or risk-management plan. A practical plan can connect each significant finding to:

• A specific action or treatment decision
• An accountable owner
• A priority
• A target date or milestone
• Required resources or dependencies
• Current status
• Evidence of implementation
• A follow-up review or validation step

Avoid vague actions such as “improve security” or “train staff.” A useful entry identifies the affected process, expected change, responsible role, completion target, and evidence that will demonstrate implementation.

Depending on the findings, actions may involve administrative, physical, or technical safeguards. Examples include:

• Revising access-authorization and termination procedures
• Removing unnecessary permissions
• Strengthening authentication
• Improving backup coverage and testing restoration
• Evaluating encryption for stored or transmitted ePHI
• Securing facilities, equipment, devices, and media
• Updating workforce training
• Formalizing incident-response procedures
• Improving logging and review
• Governing remote access
• Revising vendor oversight
• Updating policies, procedures, and business associate arrangements

These are bounded examples, not a universal control list. A safeguard is not mandatory in every circumstance or sufficient by itself merely because it appears here. Choices should respond to the entity’s actual risks, operations, resources, technical environment, and applicable requirements.

Implementation also requires verification. Purchasing a product does not establish that it is configured correctly, used consistently, or effective against the identified risk. A backup service may exist but fail to support availability if important systems are omitted or restoration cannot be completed. An access policy may appear adequate while inactive accounts remain enabled.

Risk management therefore involves more than listing future projects. It includes carrying out actions, checking results, addressing delays, recording decisions, and escalating unresolved risks to people with suitable authority.

Security Rule compliance also extends beyond the initial analysis and remediation plan. Continuing work may include policies and procedures, workforce compliance, training, business associate arrangements, incident processes, documentation, and evaluation of safeguards.

Finding risks is not itself evidence of failure. A credible analysis will often reveal weaknesses and opportunities for improvement. The central concern is whether the organization accurately evaluated relevant risks and responded appropriately—not whether its report contains an empty risk register.

Risk analysis, gap analysis, security audits, and breach assessments are not the same

A commercial compliance provider’s comparison illustrates the difference between a required risk analysis and an optional gap analysis, while the governing obligations should still be checked against current official materials. See this secondary comparison of HIPAA risk analysis and gap analysis.

Activity	Primary purpose	Typical timing	Scope	Replaces the required Security Rule risk analysis?
HIPAA Security Rule risk analysis	Identify and evaluate potential risks and vulnerabilities to ePHI	At the beginning of the Security Management Process and revisited as the environment changes	Relevant ePHI, systems, people, locations, workflows, safeguards, and external connections	This is the required analysis
Gap analysis	Compare current practices or controls with selected requirements	Often during compliance planning or program review	The requirements and practices selected for comparison	No
Technical security audit or vulnerability test	Examine technical configurations, weaknesses, or control operation	Periodically, after changes, or in response to a concern	Usually selected networks, systems, applications, devices, or controls	No
Breach-specific risk assessment	Evaluate the circumstances surrounding a particular impermissible acquisition, access, use, or disclosure	After a specific event	The facts and risks associated with that event	No
Broader privacy assessment	Examine privacy risks and obligations involving PHI in multiple forms	During privacy-program review or after relevant changes	May include electronic, paper, and verbal PHI and individual-rights processes	No

A gap analysis can reveal missing policies, controls, or documentation by comparing current practices with selected Security Rule requirements. It may give leadership a useful high-level view of the program. It nevertheless asks a different question: a gap analysis examines differences between current and expected practices, while a risk analysis examines how actual threats and vulnerabilities could affect the organization’s ePHI.

A technical audit, penetration test, vulnerability scan, or configuration review may provide strong evidence about selected systems. It may identify unsupported software, exposed services, weak settings, or missing patches. But it may not address workforce practices, physical protections, policies, vendor relationships, data flows, availability risks, or every location where ePHI resides.

A breach-specific assessment is narrower and event-driven. It follows a particular impermissible acquisition, access, use, or disclosure and addresses breach-notification questions. It is distinct from the forward-looking, environment-wide Security Rule risk analysis. A broader privacy assessment may also consider paper records, verbal disclosures, individual access rights, and other Privacy Rule concerns beyond the electronic scope of the Security Rule analysis. HIPAA Journal discusses these separate assessment contexts and their differing scopes.

Organizations can coordinate these activities to reduce duplicated effort. Technical test results can inform vulnerability findings, a gap analysis can identify missing program elements, and incident reviews can reveal changing threats. Combining evidence efficiently does not make the activities interchangeable or guarantee compliance.

Keep the analysis current—and avoid common compliance shortcuts

Risk analysis and risk management are continuing processes, not projects that end when a report is approved. Systems, vendors, threats, facilities, workflows, and business operations change. An analysis that once reflected reality may become unreliable if those changes are not considered.

Review the analysis when material developments alter the ePHI risk picture. Practical triggers include:

• Adopting a new cloud platform
• Replacing or substantially changing an EHR
• Adding remote-access methods
• Introducing connected clinical equipment
• Onboarding a major vendor or changing vendor access
• Acquiring or merging with another practice
• Opening, closing, or moving facilities
• Experiencing a security incident
• Changing backup or disaster-recovery arrangements
• Significantly revising clinical, billing, or communication workflows
• Discovering previously unrecorded ePHI or system dependencies

The appropriate review may be focused or comprehensive depending on the change. A new patient-communication platform may call for an update addressing data flows, vendor access, authentication, and transmission risks. A merger or extensive technology migration may justify a broader reassessment. This is a practical risk-management judgment rather than a universal regulatory formula.

Annual comprehensive assessment is a common third-party recommendation, but the available evidence should not be converted into a claim that every regulated organization must perform an identical full analysis on a fixed annual date. The central requirement is an accurate and thorough understanding of relevant risks and vulnerabilities. An organization can establish a regular review cadence while also using material changes and incidents as update triggers. This third-party implementation guide distinguishes its recommended cadence from the need to update the analysis as significant changes occur.

Federal health IT and HHS officials provide a Security Risk Assessment Tool intended to assist small and medium-sized healthcare practices and business associates. A tool can help structure the process, but using it does not by itself establish that the organization has completed an accurate and thorough analysis or achieved compliance. This vendor help article summarizes the tool’s availability while cautioning that an assessment is not simply a checklist or a task completed by an EHR.

Avoid these common shortcuts:

• Relying solely on a certified EHR. EHR certification does not inventory every place the organization handles ePHI or evaluate all workflows, users, facilities, vendors, and connected systems.
• Limiting the scope to one application. The primary clinical platform is only one possible location for ePHI.
• Copying a generic checklist. Templates can prompt questions but cannot provide organization-specific evidence.
• Selecting controls before understanding risks. Buying familiar products may leave important risks untreated while directing resources toward lower priorities.
• Assuming vendor assurances eliminate risk. Vendor services, access paths, dependencies, and contractual arrangements still need to be incorporated into the organization’s analysis.
• Ending after risks are listed. Findings must lead to treatment decisions, implementation, verification, and follow-up.
• Treating a clean-looking report as the goal. Credibility comes from sound evaluation and appropriate action, not from minimizing the number of recorded risks.

A practical starter sequence is:

1. Define the scope.
2. Locate and map all ePHI.
3. Identify relevant threats and vulnerabilities.
4. Review existing safeguards and supporting evidence.
5. Assess likelihood and potential impact.
6. Prioritize and document risks.
7. Assign treatment actions, owners, and targets.
8. Implement and verify safeguards.
9. Review progress and update the analysis when circumstances change.

Frequently asked questions

Is the first step called a risk analysis or a risk assessment?

The regulation uses the term risk analysis. In healthcare and compliance practice, risk assessment is also commonly used to describe substantially the same activity. Formal documentation should make clear that the organization is performing the accurate and thorough analysis of potential risks and vulnerabilities required as part of the Security Management Process.

The substance matters more than the label. Renaming a questionnaire “risk analysis” does not make it adequate, while calling a thorough, documented process a “risk assessment” does not necessarily change what it accomplishes. Define the term in organizational policies and use it consistently.

Does HIPAA require a specific risk-analysis tool, framework, or scoring method?

No universal software platform, framework, numerical matrix, or scoring formula is prescribed for every regulated entity. The method can reflect the organization’s size, complexity, capabilities, technical environment, resources, and risks. This practical compliance guide explains that multiple qualitative and quantitative approaches may be used.

Whatever method is selected should produce an accurate, thorough, supportable, and documented assessment. It should cover relevant ePHI, identify meaningful threats and vulnerabilities, consider existing safeguards, evaluate likelihood and potential impact, and produce priorities that can guide risk management.

A framework or automated tool may organize the work, but it should serve the analysis rather than define the organization’s scope by default.

Does completing a HIPAA security risk analysis make an organization compliant?

No. The analysis is foundational, but it does not prove complete HIPAA Security Rule compliance.

The organization must act on the findings through risk management and reasonable and appropriate safeguards. It must also address other applicable Security Rule responsibilities, including policies, procedures, workforce obligations, documentation, business associate relationships, and continuing evaluation. This professional-services overview places risk assessment at the start of a broader compliance process rather than treating it as a complete solution.

A completed report with unresolved high-priority findings shows that risks were identified. It does not, by itself, show that those risks were appropriately managed.

Does HIPAA require a security risk analysis every year?

The supplied evidence does not support presenting a fixed annual comprehensive analysis as a universal HIPAA mandate for every organization. Annual review is a common professional recommendation and may be a sensible internal cadence, but reviews should also respond to material changes in technology, operations, vendors, facilities, workflows, or the threat environment. This third-party guide notes the importance of updates when significant changes affect the risk picture.

The objective is to keep the analysis accurate and current. An organization should define a documented review approach and update the analysis when changes materially affect risks to ePHI rather than waiting automatically for the next calendar date.

Can a gap analysis or certified EHR replace the required risk analysis?

No. A gap analysis compares current practices with selected requirements and can support compliance planning, but it does not replace the organization-specific evaluation of risks and vulnerabilities to ePHI. This secondary comparison distinguishes the required risk analysis from an optional gap analysis.

A certified EHR also cannot perform the organization’s entire analysis on its behalf. The required scope may include email, billing applications, devices, backups, cloud services, remote access, physical locations, workforce practices, and vendor connections outside the EHR. RevolutionEHR likewise cautions that a security risk analysis is not automatically completed by a certified EHR.

Conclusion

HIPAA Security Rule compliance begins with an accurate, thorough, and documented risk analysis covering all ePHI the organization creates, receives, maintains, or transmits. The immediate practical task is to define that scope and map where ePHI resides and flows. The resulting evidence should then become prioritized risk-management actions, reasonable and appropriate safeguards, implementation records, verification, and continuing review.

This article provides general educational information, not legal advice or a determination that any particular organization is compliant. Before acting, consult current HHS guidance, the currently effective regulatory text, and qualified HIPAA legal, compliance, or healthcare-security professionals. Any publication presenting this consequential regulatory guidance should also use transparent authorship, an appropriate editorial methodology, and review by a qualified professional.