Security Risk Assessment Guide for Chronic Disease Self-Management Programs

What does a security risk assessment cover in a chronic disease self-management program?

A security risk assessment identifies how electronic protected health information (ePHI) moves through your program and what could threaten its confidentiality, integrity, or availability. Depending on how the program operates, that information might include participant names linked to diagnoses, medication or glucose readings, care plans, attendance records, or messages with a coach.

Start by mapping the ePHI your organization creates, receives, maintains, or transmits. Include the people, processes, devices, applications, facilities, and outside service providers involved—not just the program’s main software. The HHS guidance on risk analysis explains that the assessment covers all ePHI, wherever it is stored or transmitted.

Next, identify reasonably anticipated threats and security vulnerabilities, assess the safeguards already in place, and consider how likely each threat is and how serious its impact could be. The assessment should inform risk management: deciding what safeguards or other actions are needed to reduce risks to a reasonable and appropriate level.

HIPAA applies based on the organization’s role and activities, not simply because a service is called a chronic disease self-management program. Determine whether the responsible organization is a covered entity or business associate before treating HIPAA requirements as applicable.

Which program devices and systems may store or access ePHI?

Inventory any device or system that creates, receives, maintains, or transmits ePHI, as well as systems that could provide a pathway to it. For a chronic disease program, this may include:

• Staff computers, laptops, tablets, and phones used for enrollment, coaching, scheduling, or documentation.
• Electronic health record, care-management, case-management, or participant-tracking systems.
• Video-conferencing, messaging, email, file-sharing, and cloud storage services used for program activities.
• Connected health devices, such as blood glucose meters or blood pressure monitors, and associated apps or dashboards, when they transmit participant information into a covered workflow.
• Network equipment, removable media, printers, backups, and systems used for identity and access management.
• Vendor systems used for hosting, analytics, support, billing, or communication when the vendor creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate.

Whether information handled by a personal health app is ePHI under HIPAA depends on the circumstances, including who handles the information and in what role. Map the actual data flow and access arrangements rather than assuming every health-related app is covered—or that an app is outside the assessment because it is owned by a participant.

HHS recommends identifying all systems and applications that house or provide access to ePHI. Its guidance on asset inventories also notes that systems without direct ePHI may still create a pathway into systems that contain it.

How to identify and prioritize security risks to ePHI

Build an inventory of ePHI, systems, users, vendors, and data flows, then identify threats and vulnerabilities that could affect each one. Consider accidental disclosure, inappropriate access, lost or stolen devices, phishing, malware, outages, compromised vendor accounts, and failures in backup or recovery processes. Tailor the list to your program’s real environment.

For each relevant threat-and-vulnerability combination, assess both likelihood and impact. For example, a shared staff account may make unauthorized access more plausible, while a prolonged outage of the system holding participant care plans may disrupt program operations. Consider effects on confidentiality, integrity, and availability, not just the likelihood of a data breach.

Use a consistent qualitative or quantitative rating method, such as likelihood and impact scales, and document how you assign risk levels. Prioritize risks that could expose sensitive information, alter participant records, or prevent staff from accessing information needed to operate the program. HHS describes risk as involving both the likelihood of a threat exploiting a vulnerability and the resulting impact in its risk-analysis guidance.

Risk analysis identifies and evaluates risks; risk management is the follow-up work of selecting and implementing measures to reduce them. For each priority risk, assign an owner, choose a response, set a target date, and track progress. HHS explains this distinction in its risk analysis and risk management FAQ.

How to document vulnerabilities and assess confidentiality, integrity, and availability

Keep a written record of the assessment, but use a format that fits the program; the HIPAA Security Rule does not prescribe a particular template. For each finding, document the affected ePHI or system, the relevant threat and vulnerability, existing safeguards, likelihood, potential impact, assigned risk level, and the reason for that rating.

Assess the three security objectives separately:

• Confidentiality: Could someone without appropriate authorization view or disclose participant information?
• Integrity: Could information be changed, deleted, or corrupted without authorization, or become inaccurate?
• Availability: Could staff or other authorized users lose access to the information or systems they need?

Record the response to each finding, such as mitigation, acceptance with documented justification, transfer, or further investigation. Include the person responsible, due date, completion status, and any residual risk. Keep supporting evidence—such as inventories, policies, interview notes, vendor information, and relevant test results—so you can explain how you reached your conclusions.

HHS states that risk-analysis documentation is required but that no specific format is mandated. See its risk-analysis guidance and the documentation requirements in 45 CFR § 164.316.

What HIPAA Security Rule requirements apply to covered entities and business associates?

The HIPAA Security Rule applies to covered entities—health plans, health care clearinghouses, and certain health care providers—and to business associates that handle ePHI on behalf of a covered entity or another business associate. A program itself is not automatically a covered entity. Identify the legal organization responsible for it and assess whether that organization meets the rule’s definitions. HHS summarizes who is covered in its HIPAA Security Rule overview.

Under the current rule, covered entities and business associates must conduct an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. They must also implement security measures to reduce risks and vulnerabilities to a reasonable and appropriate level. The Security Rule calls for administrative, physical, and technical safeguards, along with required policies, procedures, and documentation. See 45 CFR § 164.308 and HHS’s summary of the rule.

When a vendor qualifies as a business associate, the covered entity generally needs a written business associate agreement that meets HIPAA requirements. The agreement does not replace each party’s responsibility to address the risks in its own environment. HHS explains these obligations in its business associate guidance.

HHS has proposed changes to the Security Rule, but its current rule page states that the current Security Rule remains in effect while rulemaking is underway. Treat a proposal as a proposal—not as a current requirement. Check HHS’s Security Rule NPRM page for its status and distinguish proposed provisions from the requirements currently in force.

When to repeat an assessment after annual reviews or technology changes

The HIPAA Security Rule requires ongoing risk analysis and periodic evaluation, but it does not set one universal annual schedule for completing a risk assessment. How often you reassess depends on your environment and the risks to ePHI. An annual review may be a useful organizational practice, but it should not replace updates when important changes occur.

Review the assessment when you introduce a new platform or connected device, change vendors, alter data flows, open a new program site, experience a security incident, or identify a new vulnerability. Consider risks before implementing a change where possible, then update the assessment and risk-management actions as needed.

HHS advises that risk analysis should be ongoing and describes new technology, security incidents, and changes in operations as reasons to revisit risks. The HHS risk-analysis guidance explains that the rule does not specify a single frequency. The separate evaluation standard requires periodic technical and nontechnical evaluation; see 45 CFR § 164.308(a)(8).

What are the limits of using a risk assessment tool?

A tool can organize questions, prompt you to consider common safeguards, and help document findings. It cannot automatically identify every asset, data flow, threat, or vulnerability in your program. Its results depend on accurate information, informed answers, and an assessment process that reflects the organization’s actual environment.

Completing a questionnaire or receiving a score does not establish that all risks have been assessed, that identified problems have been addressed, or that your organization is HIPAA compliant. HHS says there is no single method or best practice that guarantees compliance. Its Security Risk Assessment Tool user guide describes the tool as an aid to assessment and documentation, not proof of compliance.

Use a tool as one part of a broader process: verify its coverage, involve people who understand the program’s systems and workflows, follow up on findings, and update the assessment when risks change. In short, map ePHI, evaluate threats and vulnerabilities across confidentiality, integrity, and availability, document decisions, and carry the findings into ongoing risk management.

FAQs.

Are chronic disease self-management programs required to conduct a HIPAA security risk assessment?

Not solely because they are chronic disease self-management programs. The requirement applies to HIPAA covered entities and business associates handling ePHI in those roles. If the program is operated by or for a covered entity, determine whether its activities and partners bring it within the Security Rule. HHS describes the covered organizations and the risk-analysis requirement in its Security Rule overview.

Does a risk assessment tool guarantee HIPAA compliance?

No. A tool can support the assessment and help document it, but it cannot guarantee that the assessment is accurate, complete, or followed by effective risk management. HHS states that no single method guarantees compliance in its risk-analysis guidance.

Which devices may create, store, or transmit ePHI?

Potential examples include staff computers and phones, tablets used for coaching, EHRs and care-management systems, email and video platforms, connected health devices and related dashboards, cloud storage, backups, removable media, and vendor systems. Include systems that can provide access to ePHI even if they do not directly store it, and confirm how information actually flows through your program.

When should a program repeat its security risk assessment?

Conduct it on a schedule suited to your environment and revisit it when meaningful changes or newly recognized risks may affect ePHI—for example, a new technology or vendor, a change in operations, or a security incident. HIPAA does not specify a universal annual risk-assessment deadline; HHS says frequency varies by circumstances in its risk-analysis guidance.