HIPAA Security Risk Assessment: Steps for Software Teams

A HIPAA security risk assessment maps every ePHI flow, evaluates threats and vulnerabilities, checks current safeguards, ranks risk, and turns the results into a remediation plan. For software teams, the output should affect architecture, sprint work, vendor decisions, test plans, and launch gates, rather than sit in a compliance folder.

What a HIPAA security risk assessment must prove

A HIPAA security risk assessment should prove that your organization knows where ePHI lives, how it moves, who can access it, what could go wrong, which safeguards exist, and which gaps remain. It should also prove that risks were rated consistently, documented, assigned to owners, and reviewed after material product or operational changes.

HHS OCR describes risk analysis as an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. Its risk analysis guidance also makes one point clear for product teams: all ePHI created, received, maintained, or transmitted by the organization is in scope.

That scope includes more than patient records in a production database. It can include intake forms, chat messages, uploaded files, lab results, wearable data, call recordings, appointment notes, support tickets, application logs, backups, analytics exports, and data passed through third-party tools.

A practical HIPAA risk analysis should document:

• The systems, environments, users, vendors, and workflows in scope
• Where ePHI is created, received, maintained, processed, stored, and transmitted
• Reasonable threats and vulnerabilities for those systems
• Current administrative, physical, and technical safeguards
• Likelihood and impact for each risk
• Risk level and remediation priority
• Evidence behind each decision
• Periodic updates and reassessment triggers

NIST SP 800-66 Rev. 2, published in February 2024, gives regulated entities and business associates practical guidance for safeguarding ePHI and mapping HIPAA Security Rule concepts to security practices. Use NIST SP 800-66 Rev. 2 as an operational reference, while keeping final interpretation with your compliance owner and counsel.

HHS has also issued a proposed Security Rule update that points toward more specific expectations, such as technology asset inventories, network maps, written risk analysis, encryption, MFA, vulnerability scanning, penetration testing, segmentation, and backup recovery controls. Treat the NPRM fact sheet as planning input until a final rule applies.

Step-by-step HIPAA risk assessment process for software teams

Software teams need a process that combines compliance scope with engineering evidence. Start with ePHI and system boundaries, then inspect controls, score risk, create backlog items, and verify fixes. A worksheet can guide the work, but it cannot replace documented analysis, decision history, and proof that remediation occurred.

1. Define the assessment scope

List every product, portal, mobile app, backend service, cloud account, database, file store, analytics tool, support tool, vendor, and integration that can touch ePHI. Include staging and QA if test data contains production records or realistic patient data.

Define who owns the assessment: compliance, security, CTO, product, engineering, DevOps, customer support, and any vendor representatives who need to supply evidence.

1. Inventory ePHI and map data flows

Map how ePHI enters the system, where it is processed, where it is stored, and where it leaves. For each flow, record:

• Data type, such as demographics, clinical notes, wearable signals, insurance details, messages, or files
• Source, such as patient app, clinician portal, EHR, device, form, or API
• Destination, such as database, cloud storage, email service, analytics tool, or support queue
• Transport method and encryption status
• Retention period and deletion path
• User roles and service accounts with access

This map becomes the base for architecture review, threat modeling, access control, logging, and vendor review.

1. Build an asset and vendor inventory

Record the systems and services that support each flow. Include application servers, databases, object storage, queues, caches, CI/CD systems, monitoring tools, authentication services, mobile SDKs, email/SMS providers, analytics platforms, call systems, telehealth tools, and backup services.

For each vendor, confirm whether it handles ePHI, whether a business associate agreement is needed, who owns configuration, and what evidence is available for security review.

1. Collect evidence for current safeguards

Evidence should come from actual system behavior, not assumptions. Pull configuration records, access control matrices, encryption settings, backup settings, audit log samples, incident response procedures, access review records, vulnerability reports, dependency scans, architecture notes, and release checklists.

Separate safeguards into HIPAA Security Rule categories:

• Administrative safeguards: policies, assigned security responsibility, access approval, workforce training, incident response, vendor review, risk management
• Physical safeguards: device controls, office access, workstation use, media handling, endpoint protections, cloud provider responsibility boundaries
• Technical safeguards: access controls, authentication, audit controls, integrity controls, encryption, transmission security, session handling

1. Identify threats and vulnerabilities

Threats are events that can harm confidentiality, integrity, or availability of ePHI. Vulnerabilities are weaknesses that make those events more likely or more damaging.

Common examples include weak admin authentication, overbroad clinician access, missing audit logs, exposed storage buckets, insecure APIs, vulnerable dependencies, unencrypted backups, incomplete vendor contracts, support staff access without review, and mobile data remaining on a lost device.

1. Rate likelihood and impact

Use a simple, documented method. For likelihood, consider exposure, exploitability, access paths, control strength, and history of incidents. For impact, consider ePHI volume, sensitivity, patient safety effect, regulatory exposure, operational downtime, and breach response effort.

Whether you use low/medium/high or a numeric score, define the scale before scoring. Keep the rationale short and specific.

1. Create a remediation plan

Convert each risk into an owner, due date, acceptance criteria, test method, and evidence requirement. Security findings should become product backlog items, infrastructure tickets, vendor tasks, or policy updates.

A useful risk management plan connects compliance findings to delivery work. For example, "admin MFA missing" becomes a specific authentication ticket with rollout scope, test evidence, release date, and access review records.

1. Validate fixes

Close findings only after verification. That may require code review, configuration review, automated tests, vulnerability scans, penetration testing, access review, log inspection, backup restore testing, or vendor evidence.

Keep proof that the risk was reduced. Screenshots alone are weak unless they are paired with ticket history, configuration exports, test results, approval records, or monitoring evidence.

1. Schedule reassessment

Put reassessment into the operating rhythm. A HIPAA risk assessment checklist can help teams remember categories, but the assessment remains an ongoing analysis tied to product change, not a single annual document.

What to inspect in a healthcare app or platform

Healthcare app security reviews should inspect the full product surface, rather than only the database. ePHI can pass through mobile storage, APIs, notifications, analytics, logs, support tools, cloud services, backups, and admin portals. The assessment should trace these paths against access rules, auditability, encryption, retention, and vendor responsibilities.

In the RAE Health project, Attract Group built a healthcare app and clinical web portal around wearable signals, stress and craving events, mobile exercises, RAE Connect visibility, analytics-oriented workflows, and an AWS-heavy backend. A product like this shows why ePHI mapping has to cover mobile users, provider or caregiver visibility, clinical portals, backend processing, and analytics workflows.

For a healthcare platform, inspect these areas:

• Authentication and sessions: password policy, SSO, MFA for privileged users, token lifetime, refresh token handling, session timeout, device trust, account recovery, and brute-force protection.
• Role-based access: patient, clinician, caregiver, admin, support, billing, researcher, and integration roles. Review what each role can view, create, edit, export, delete, and delegate.
• ePHI inventory: clinical data, messages, attachments, wearable signals, surveys, appointment data, prescriptions, billing fields, insurance records, and metadata that can identify a patient.
• APIs: authorization checks, object-level access, rate limits, schema validation, error handling, logging, versioning, and exposure through mobile clients or partner systems.
• EHR, FHIR, and HL7 interfaces: inbound and outbound ePHI, transformation logic, interface engine access, retry queues, failed-message storage, and reconciliation workflows.
• Audit logs: user ID, patient record ID, action, timestamp, source IP or device, admin changes, export activity, failed login attempts, and log retention.
• Application logs: confirm that logs do not capture clinical notes, tokens, full identifiers, request bodies, uploaded files, or debug traces containing ePHI.
• Encryption: data in transit, data at rest, secrets management, certificate handling, backup encryption, and mobile storage protections.
• Cloud resources: account structure, network boundaries, IAM roles, storage permissions, database exposure, backup policies, monitoring, and incident alerts. For cloud-specific design patterns, see HIPAA-compliant cloud architecture.
• Admin portals: privileged workflows, impersonation controls, export functions, audit trails, approval flows, and access reviews.
• Notifications: SMS, email, push notifications, voicemail, and in-app alerts. Confirm whether message content exposes ePHI.
• Mobile storage: local databases, caches, files, screenshots, clipboard behavior, biometric unlock, jailbreak or root checks, and data wipe behavior.
• Vendor tools: support desks, analytics SDKs, crash reporting, email providers, telehealth tools, transcription services, and observability platforms.
• Backups and recovery: backup frequency, restore tests, retention, access restrictions, recovery time targets, and ransomware recovery assumptions.
• Testing and release gates: static analysis, dependency scanning, API testing, mobile testing, penetration testing, privacy review, and sign-off for releases that change ePHI scope.

This inspection should be tied to how the product is actually used. A clinician dashboard, patient mobile app, and admin support panel may all touch the same record but create different risk paths.

Risk scoring and remediation outputs

Risk scoring should convert observations into decisions that product and engineering teams can act on. Each finding needs a clear threat, affected ePHI, current safeguard, likelihood, impact, rating, owner, due date, and verification method. The result is a risk management plan tied to backlog work and evidence.

A simple scoring model is usually enough if it is defined and applied consistently. For example:

• Likelihood: low, medium, high
• Impact: low, medium, high
• Risk level: based on a documented matrix
• Treatment: remediate, reduce, transfer, accept, or avoid
• Residual risk: what remains after remediation

Avoid rating every issue as high. That makes prioritization impossible. Also avoid accepting risk without a named business owner and written rationale.

Remediation should be specific enough for engineering execution. "Improve access control" is too vague. "Add server-side object-level authorization to the appointment endpoint and test patient, clinician, and admin access paths" is actionable.

Connect findings to release gates. A high-risk issue that affects broad ePHI access should block launch until the control is built, tested, and documented. Lower-risk items may move into a dated remediation plan if the compliance owner accepts that path.

When to reassess and how to keep evidence current

A HIPAA risk analysis is not a one-time launch task. Reassess when the product scope changes, ePHI moves to a new place, a vendor or integration changes, or an incident reveals a weak control. Keep evidence current so an audit or OCR inquiry can reconstruct what was known and done.

Use both calendar-based and event-based reassessment. Annual review may help, but it is not enough for a fast-moving healthcare product.

Trigger a reassessment when you add or change:

• A new product module that creates, stores, or displays ePHI
• A new mobile feature that caches patient data
• A new clinician, caregiver, school, payer, or admin role
• A new EHR, FHIR, HL7, lab, device, or telehealth integration
• A cloud migration or major infrastructure redesign
• A new analytics, messaging, support, monitoring, or AI vendor
• A release that changes PHI scope or data retention
• A security incident, near miss, or privacy complaint
• A major permission model change
• A backup, disaster recovery, or incident response process change

Keep an evidence folder or repository that includes:

• Current ePHI inventory and data-flow maps
• Architecture diagrams and network maps
• Asset and vendor inventory
• BAA status for vendors handling ePHI
• Access control matrix and access review records
• Encryption, backup, monitoring, and logging configuration evidence
• Security test reports, including vulnerability scans and penetration test results
• Remediation tickets with acceptance criteria and verification
• Release notes for changes affecting ePHI
• Risk acceptance records with owner approval
• Incident response exercises and backup restore tests

Evidence should be easy to trace. If a finding says audit logs were incomplete, the closure record should point to the code change, configuration change, test result, and sample audit event.

Common mistakes in HIPAA risk assessments

The most common mistakes come from treating HIPAA as paperwork instead of system behavior. Teams miss ePHI in logs, overlook admin tools, ignore vendor access, reuse generic checklists, or rate every risk the same. These errors make the assessment weak even when the application has some security controls.

Common issues include:

• Using a checklist as the assessment. A checklist can prompt questions, but it does not prove scope, likelihood, impact, safeguards, or remediation.
• Mapping only production databases. ePHI may exist in mobile caches, staging systems, analytics exports, object storage, logs, emails, support tickets, and backups.
• Ignoring admin and support workflows. Internal users often have broad visibility. Their access needs strict role rules, approval, audit logs, and periodic review.
• Assuming cloud compliance covers the app. Cloud providers may supply compliant infrastructure options, but application configuration, IAM, logging, encryption choices, and data flows remain your responsibility.
• Missing vendor data paths. Crash reporting, messaging, analytics, telehealth, transcription, and customer support tools can receive identifiers or clinical context.
• Failing to test authorization. Role matrices are useful only if APIs enforce them. Object-level access tests should cover patient, clinician, caregiver, admin, and support paths.
• Letting logs leak ePHI. Debugging convenience can create uncontrolled records of clinical or identifying data.
• Keeping weak evidence. "Fixed" in a ticket is not enough. Keep test output, configuration proof, review records, and release references.
• Skipping reassessment after product changes. New modules, integrations, and vendors can change the risk profile overnight.
• Separating compliance findings from engineering work. Findings should become backlog items, architecture decisions, tests, and release gates.

Security testing deserves special attention. HIPAA does not name every test in the same way a technical standard might, but software teams need evidence that controls work. For practical testing scope, see HIPAA penetration testing.

How a development partner should support the assessment

A development partner should help turn assessment findings into software, infrastructure, and release evidence. That means reviewing architecture, translating risks into backlog items, designing controls, supporting vendor inventories, preparing test evidence, and making sure remediation survives future releases. The partner should not replace counsel or the compliance owner.

Look for support in these areas:

• Architecture review: data flows, trust boundaries, cloud design, integrations, tenant separation, and admin access.
• Backlog translation: clear tickets for access control, audit logging, encryption, retention, notification changes, vendor replacement, or data minimization.
• Role and permission design: RBAC or attribute-based access, approval workflows, support access, impersonation limits, and access review reports.
• Cloud implementation: IAM, network segmentation, storage permissions, logging, monitoring, backup recovery, and secure deployment paths.
• Vendor and BAA support: inventory inputs, data-flow notes, vendor configuration, and evidence collection for compliance review.
• Security testing: API testing, mobile testing, dependency review, vulnerability scanning, and penetration testing services when the risk profile calls for deeper testing.
• Release evidence: test results, review records, migration notes, configuration records, and sign-off packages for features affecting ePHI.

If your assessment found gaps in the product, use the findings as delivery input for HIPAA-compliant app development or broader healthcare software development. The best outcome is a system where ePHI flow, access control, logging, cloud architecture, vendors, testing, and release decisions can all be explained with current evidence.

Vladimir Terekhov

Co-founder and CEO at Attract Group