Healthcare data rarely stays inside one EHR, SaaS platform, cloud account, or data center boundary. A patient-facing workflow can touch an EHR, integration service, cloud database, analytics environment, support ticket, collaboration file, and backup platform. Security and GRC teams still have to prove which systems are in scope, who owns each control, which risks remain open, and whether evidence reflects the current environment.
The scale of that operating problem is visible in HHS breach data. For breaches affecting 500 or more individuals that occurred in 2024, OCR received 663 reports affecting approximately 242.9 million individuals. Hacking and IT incidents accounted for 81% of those reports.
The strongest healthcare data security best practices connect policy, risk analysis, controls, ownership, remediation, evidence, audit preparation, training, and recovery into one working program.
For threat context, see the four major healthcare data security challenges facing hospitals and health plans in 2026.
Key insights
- Healthcare data security protects confidentiality, integrity, and availability, but in healthcare those properties affect privacy, fraud exposure, clinical workflows, and continuity of care.
- Security scope follows healthcare data through EHRs, SaaS, cloud workloads, exports, backups, connected devices, and third parties.
- Inventory is a control dependency. Patching, access reviews, vulnerability ownership, recovery, and evidence collection all depend on reliable asset and data scope.
- Vulnerability discovery does not reduce risk until remediation has an owner, deadline, validation step, and retained evidence.
- Audit readiness should emerge from normal control operation, while training and recovery priorities should reflect actual authority, access, and operational criticality.
What data protection and security in healthcare actually covers
Data protection and security in healthcare covers every system, workflow, identity, copy, integration, and third party involved in creating, receiving, maintaining, processing, or transmitting sensitive healthcare data.
For HIPAA-regulated organizations, that scope includes ePHI created, received, maintained, or transmitted by covered entities and Business Associates. NIST SP 800-66 Rev. 2 provides implementation guidance for applying the HIPAA Security Rule and managing risks to ePHI.
Operational scope can include:
- EHR and EMR systems
- Claims and billing platforms
- Payer portals
- Imaging and laboratory systems
- Telehealth applications
- SaaS platforms
- Cloud databases, object storage, and analytics workloads
- Backups and disaster recovery copies
- Support tickets and attachments
- Business Associate and Subcontractor systems
- Connected clinical and medical devices
The security boundary follows the data flow. An EHR-connected application may send selected records through an integration layer, write transformed data into cloud storage, expose reporting through another application, and send a subset to a Business Associate.
| Security property | Healthcare consequence |
|---|---|
| Confidentiality | Privacy, fraud exposure, regulatory risk, and patient trust |
| Integrity | Trust in clinical, billing, and operational records |
| Availability | Access to care systems, communications, prescriptions, histories, and device functions |
For the broader multi-cloud operating model, see our complete guide to healthcare data security.
Build a healthcare data security policy the GRC team can enforce
A healthcare data security policy becomes enforceable when regulatory expectations are translated into system scope, control ownership, exception handling, and evidence.
OCR’s March 2026 MMG Fusion settlement shows why policy cannot sit apart from execution. The matter involved a breach affecting approximately 15 million individuals, and the corrective action requirements connected risk analysis, risk management, written policies and procedures, and workforce training.
For a GRC team, the practical unit is not the policy statement. It is the chain from requirement to implementation and proof.
Map policy statements to safeguards, systems, and owners
Take a common policy requirement: access to ePHI must be limited according to job responsibility and business need. That statement needs an implementation chain.
“A policy becomes hard to defend when the team cannot trace a requirement to the system it covers, the person responsible for it, and the evidence showing it operated. The audit usually exposes a traceability problem that already existed in daily work.” — Alla L., Technical Account Manager at Cloudaware
The table below shows how to make that traceability explicit by linking each policy statement to its system scope, accountable owner, exception path, and operating evidence.
| Policy statement | Required operational mapping |
|---|---|
| Access to ePHI is limited by role | Workforce role, system, identity group, privilege level, review cadence, emergency access path, evidence |
| ePHI transmission must be protected | Data flow, system owner, encryption requirement, key owner, exception path, validation evidence |
| Audit activity must be reviewed | Log source, review owner, review cadence, escalation trigger, retained evidence |
| Exceptions must be approved | Affected requirement, business rationale, compensating control, approver, review date, expiry date |
A data security policy in healthcare should define how implementation, exception approval, review, and evidence work, not only what the organization expects employees and systems to do.
Turn policy into a healthcare data security plan
A healthcare data security plan turns risk analysis into owned, prioritized, and verifiable work.
HHS treats risk analysis as foundational to the Security Rule’s risk-management process, while NIST SP 800-66 Rev. 2 provides implementation guidance for safeguarding ePHI. The gap appears when analysis ends in a report rather than becoming treatment work.
A usable risk record should identify the affected system, data scope, business-service context, exposure path, current safeguards, likelihood and impact rationale, accountable owner, and evidence requirement.
| Plan field | Why GRC needs it |
|---|---|
| Risk owner | Accepts or escalates residual risk |
| Remediation owner | Changes the system or process |
| Evidence owner | Proves the action happened |
| Exception approver | Accepts temporary deviation |
| Review date | Prevents permanent exception drift |
| Validation method | Confirms the risk state changed |
| Escalation trigger | Defines when overdue or high-risk work moves up |
This is where a healthcare security plan overlaps with an ISO 27001 risk assessment: both require scope, ownership, treatment decisions, acceptance criteria, and retained evidence.
OCR’s MMG Fusion guidance recommends periodic updates to risk analysis and maintenance of a risk management plan for risks to the confidentiality, integrity, and availability of ePHI. A finding list can grow without changing the environment. A plan has to move each finding through treatment, exception, acceptance, or escalation.
Data security measures in healthcare: build a layered control stack
Effective data security measures in healthcare should produce decisions, not just control coverage. A GRC or security team should be able to look at a system, user, file, finding, device, or third-party connection and determine the risk, owner, action, and proof.
The 2026 Verizon Healthcare Snapshot analyzed 1,492 healthcare incidents, including 1,438 confirmed breaches. Its healthcare breakdown shows multiple initial access paths, including vulnerability exploitation, phishing, and credential abuse.
That mix requires controls across infrastructure, identity, data movement, human workflow, third-party access, and recovery.
1. Maintain an asset and data-flow inventory that can drive action
HHS OCR’s January 2026 cybersecurity guidance connects hardening and vulnerability management with knowing which systems need protection, including EHR software, databases, web servers, mobile applications, firmware, routers, and firewalls.
In healthcare, asset inventory fails when it stops at “what exists.” Security teams also need to know whether the asset is in ePHI scope, reachable from the internet or a vendor network, tied to a clinical workflow, and owned by a team that can remediate findings.
A usable inventory should answer:
- Which application or clinical workflow depends on this asset
- Which AWS account, Azure subscription, GCP project, VMware environment, or SaaS system contains it
- Whether it stores, processes, transmits, logs, or backs up ePHI
- Whether it is internet-facing, vendor-accessible, or connected to a medical-device segment
- Who owns remediation and evidence
- Which open findings, exceptions, and overdue reviews apply
Inventory shows what exists. Network visibility shows what assets are doing. Healthcare teams need both because ePHI exposure often comes from integrations, exports, backups, support systems, and unmanaged dependencies.
Example Cloudaware CMDB view showing how a cloud asset connects to related configuration items, application context, and operational dependencies.
2. Review access by role, system, and exception status
A 2026 HHS OIG audit of a large southeastern hospital found that an account-management web application lacked strong identification and authentication controls such as MFA. OIG used credentials captured during its phishing campaign to gain access to account management.
The lesson is not only “turn on MFA.” The problem is that captured credentials became usable because the access path did not enforce stronger authentication.
Healthcare access reviews should focus first on high-risk paths:
- Privileged users
- Break-glass and emergency access
- Service desk reset permissions
- Vendor and contractor accounts
- Dormant accounts
- Shared or generic accounts
- Admin access to systems that store or support ePHI
Each review should produce one decision: keep, remove, downgrade, expire, or document as an exception. For emergency access, the review should also confirm who used it, why it was used, what activity occurred, and whether post-access review was completed.
3. Make every ePHI export and secondary copy traceable
Healthcare data exposure often happens after information leaves the primary system. Metomic’s Healthcare Data Crisis found that 25% of publicly shared files in its healthcare dataset contained PII. This is evidence from one vendor’s dataset, not an industry-wide prevalence rate, but it highlights a familiar operational risk: sensitive data spreads through normal work.
That includes EHR data exported for analytics, claims downloaded as CSV files, screenshots attached to support tickets, test datasets copied from production, files sent to vendors for troubleshooting, and shared folders that retain external access long after the work ends.
For every high-risk copy, record:
- Owner
- Business purpose
- Destination
- Access boundary
- Retention period
- Review date
- Evidence of deletion or access revocation
4. Encrypt data and govern key usage
The HIPAA Security Rule includes transmission-security requirements for ePHI transmitted over electronic communications networks. NIST SP 800-66 Rev. 2 treats cryptographic controls as part of a broader safeguard program rather than as a substitute for access control, monitoring, or risk management.
Healthcare teams should verify:
- Which databases, buckets, disks, backups, snapshots, and exports require encryption
- Which APIs, integrations, file transfers, and admin paths require protected transmission
- Which identities can administer keys
- Which identities can use keys for decryption
- Whether key-use logs are enabled and reviewed
- Whether replicas, analytics copies, and test datasets remain covered
- Whether key administration is separated from data administration where risk requires it
For example, here is how healthcare orgs get this info in Cloudaware dashboards:
Cloudaware dashboard view for tracking encryption and key management posture across cloud assets.
5. Preserve audit activity that can support investigation
The HIPAA Security Rule requires mechanisms to record and examine activity in systems that contain or use ePHI. HHS guidance also points to reviewing audit logs, access reports, and security incident tracking reports like:
A logging program is weak when logs exist but cannot support an investigation. For in-scope systems, teams should confirm coverage for authentication, privileged access, ePHI access or export, IAM changes, configuration changes, sharing changes, backup activity, restore activity, deletion, and key use.
6. Manage configuration drift with ownership and validation
The HHS Healthcare and Public Health Cybersecurity Performance Goals include configuration management among enhanced goals for healthcare organizations.
Configuration drift becomes a security problem when the team detects a deviation but cannot assign ownership, approve an exception, validate the fix, or prove what changed.
In healthcare environments, high-risk drift includes public storage exposure, disabled MFA, disabled logging, changed encryption settings, opened security groups, removed backup policies, and default credentials on devices or management interfaces.
The control needs four records:
- Approved baseline
- Current observed state
- Owner decision
- Validation evidence
For example, like this:
Cloudaware compliance dashboard showing failed checks, policy status, and historical posture signals across cloud environments.
7. Prioritize vulnerabilities by exposure, ownership, and clinical context
OCR’s January 2026 guidance shows ongoing vulnerability identification, hardening, and patching. Vulnerability intelligence does not reduce risk by itself. Risk changes when the organization patches, isolates, reconfigures, coordinates with a vendor, or documents a temporary exception with compensating controls and a review date.
Healthcare teams should not prioritize by CVSS alone. The same vulnerability can require different treatment depending on exposure, ownership, clinical dependency, and patch feasibility.
Prioritization should account for:
- Internet exposure
- Application or service context
- Environment
- ePHI or compliance scope
- Known exploitation
- Vendor-managed status
- Patch availability
- Clinical or operational dependency
- Existing segmentation or monitoring
- Closure evidence
Exactly these criteria Cloudaware uses for prioritization, like:
“A vulnerability report tells you that something is wrong. It does not tell you who owns the workload, whether the asset supports a critical service, or who is responsible for closing the finding. That context is what turns detection into remediation.” — Igor K., DevOps Engineer at Cloudaware
8. Segment systems and verify allowed communication paths
The HHS Healthcare and Public Health Cybersecurity Performance Goals include network segmentation among enhanced goals for healthcare organizations.
| Review question | Output |
|---|---|
| Which systems must communicate for the workflow | Approved path list |
| Which paths are legacy or undocumented | Removal or review queue |
| Which systems can reach identity services, databases, management planes, or backups | Exposure map |
| Which vendors have network paths into the environment | Third-party access record |
| Which connected devices cannot be patched quickly | Isolation or compensating-control decision |
| Which traffic patterns would indicate unexpected behavior | Monitoring rule or escalation trigger |
Segmentation decisions should reflect actual dependencies, vendor constraints, exposure paths, monitoring coverage, and operational criticality.
9. Test recovery around care continuity
In healthcare, cyber risk is also a care-continuity risk. Loss of access to clinical systems, communications, prescriptions, patient histories, or device functions can affect care delivery.
A backup report only proves that data was copied. A recovery test should prove that the organization can restore the right services in the right order.
The test should confirm:
- Which systems restore first
- Whether identity services are available
- Whether EHR access depends on other services
- Whether integration services recover before downstream workflows
- Whether teams can communicate if primary tools are unavailable
- Whether manual downtime procedures work
- Whether restored data is complete and usable
- Who approves return to service
- Which gaps become corrective actions
Recovery order should follow operational dependency, not infrastructure convenience. Identity, communications, EHR access, integration services, and critical clinical dependencies may need priority over lower-risk administrative systems.
Cloudaware related-CI view showing dependencies around a cloud compute resource, useful for recovery and impact analysis.
10. Govern third-party and Business Associate access
Third parties were involved in 32% of healthcare breaches in Verizon’s 2026 healthcare dataset.
For each vendor or Business Associate, teams need a live access record. The failure mechanism is usually a gap between contract scope and live access. A vendor relationship may end while service accounts, VPN paths, local users, or API keys remain active. Governance should connect vendor lifecycle, identity records, system access, data scope, and review cadence.
For incident mechanics, see our analysis of recent healthcare data breaches.
Secure ePHI across EHR, SaaS, cloud, and hybrid infrastructure
Healthcare cloud security depends on proving which services process ePHI, who can access them, who owns them, and which evidence shows their current control state.
Cloud providers treat healthcare compliance as a shared operating responsibility. AWS states that customers should process, store, and transmit PHI only in HIPAA-eligible services covered by the relevant BAA. Microsoft provides a BAA for in-scope services but states that using Microsoft services does not by itself achieve HIPAA compliance. Google Cloud assigns customers responsibility for properly configuring and securing the environments and applications they build.
A BAA establishes responsibilities. It does not configure the workload, validate IAM, review logs, govern secondary copies, or prove that only approved services process ePHI.
Discover where ePHI-related workloads and dependencies exist
Sensitive information can spread through ordinary work, not only through formal healthcare data pipelines. Metomic’s report describes examples such as HR exports in broadly shared spreadsheets, CSV files downloaded for one-off analysis, customer data used in testing, Jira records and attachments containing PII or PHI, stale external sharing permissions, and passwords or secrets inside shared files.
These examples show how sensitive data leaves the system of record through collaboration, support, analytics, and development workflows.
Cloud data controls should follow the complete lifecycle. Our cloud data security best practices guide covers discovery, classification, access, drift, evidence, and recovery across multi-cloud data stores.
Connect assets, owners, and control evidence
A public-storage finding is easier to prioritize when the security team can see that the resource belongs to a production application, falls within a healthcare compliance scope, has a named owner, and already has or lacks an approved exception.
“A cloud resource only becomes operationally useful to security when it is connected to the application it supports, the environment it belongs to, and the team that owns the fix. Otherwise, the finding still needs manual reconstruction before anyone can act.” — Katerina L., Cloud Security Expert at Cloudaware
Prepare for healthcare data security audits continuously
Healthcare data security audits are easier to manage when evidence is collected as controls operate instead of being reconstructed shortly before assessment.
HHS OCR’s 2024–2025 HIPAA audit cycle reviews 50 covered entities and Business Associates against selected Security Rule provisions relevant to hacking and ransomware. OCR says it will publish an industry report after the audits are completed.
- Define scope. Identify entities, systems, environments, and data flows covered by the review.
- Reconcile inventory. Confirm that in-scope systems still exist and that new resources have not appeared outside the working inventory.
- Map controls to owners. Assign implementation and evidence ownership.
- Collect technical and procedural evidence. Include access reviews, activity-review records, risk analysis, remediation records, incident plans, contingency plans, BAAs, exceptions, and training attestations where relevant.
- Review findings and exceptions. Confirm owner, rationale, compensating control, deadline, review date, and expiry.
- Validate corrective actions. Verify that the environment changed as intended.
- Check evidence freshness. Separate historical proof from evidence of current operation.
- Return findings to the risk program. Create or update owned risk and remediation records.
Historical continuity matters. OCR guidance on recognized security practices states that, in certain Security Rule enforcement and audit activities, OCR must consider whether the regulated entity can demonstrate that recognized security practices were in place during the prior 12 months.
“An audit packet should be the output of controls operating throughout the year. When teams have to rebuild ownership, exceptions, approvals, and evidence just before an assessment, the real problem started months earlier.” — Igor K., DevOps Engineer at Cloudaware
Make healthcare cybersecurity training role-specific and provable
Healthcare cybersecurity training should reflect what a workforce member can access, change, approve, export, disclose, or recover.
The 2026 Verizon Healthcare Snapshot found a human element in 54% of healthcare breaches in its dataset. OCR’s MMG Fusion guidance also recommends regular training specific to the organization and workforce members’ respective job duties.
| Role | Relevant training scenario |
|---|---|
| Clinical workforce | Misdelivery, suspicious MFA prompts, emergency access |
| Service desk | Identity verification, reset abuse, impersonation |
| Developer | Secrets, test data, unsafe production-data copies |
| Cloud administrator | IAM changes, public exposure, logging changes |
| Privileged user | Administrative-account separation and elevated-access review |
| GRC team | Exception expiry, evidence handling, escalation |
The operating model is people + process + technology. Training teaches a workforce member what to recognize. The process defines how to report or escalate it. Technical controls limit the consequence of mistakes.
Completion percentage alone says little about operational readiness. More useful measures include overdue training, privileged-user coverage, repeated simulation failures by role, recurring incident patterns, and required attestation status.
Run healthcare data security as a continuous GRC operating loop
Healthcare data security becomes sustainable when policy, risk findings, controls, evidence, audits, training, and corrective actions update one another.
OCR’s January 2026 cybersecurity guidance emphasizes that hardening and related security work require ongoing attention as systems and vulnerabilities change. The MMG Fusion corrective action structure also connects risk analysis, risk management, policy, and training rather than treating them as isolated compliance activities.
The operating loop is:
- Policy defines expected state.
- Risk analysis identifies deviations and exposure.
- The healthcare data security plan assigns treatment and ownership.
- Technical and administrative controls change the environment.
- Monitoring and evidence test the resulting control state.
- Audits and incidents expose residual gaps or failed assumptions.
- Training and corrective action address recurring causes.
- Policy, scope, and risk assumptions are updated.
This loop only works when teams measure movement through the system, not the amount of security activity produced. A scan, alert, policy, or audit artifact is useful only if it changes ownership, treatment, validation, or evidence quality. Otherwise, the program can look active while risk stays unresolved.
| Weak metric | Better metric |
|---|---|
| Number of scans completed | Percentage of critical findings with owners and due dates |
| Number of alerts | Percentage of findings validated, remediated, or formally excepted |
| Training completion rate | Privileged-user and role-specific training coverage |
| Number of policies | Percentage of policy requirements mapped to evidence |
| Number of audit artifacts | Evidence freshness and unresolved exception age |
Healthcare data security best practices checklist for GRC teams
The strongest healthcare data security best practices make scope, ownership, control state, exceptions, recovery readiness, and evidence easy to verify.
Make healthcare security evidence operational, not episodic
Healthcare security operations become easier when teams can trace an in-scope asset to its application, owner, control state, findings, exceptions, remediation records, and current evidence.
Cloudaware supports that operating model across cloud and hybrid infrastructure through three related capabilities:
- CMDB-backed inventory: Track assets across AWS, Azure, GCP, Oracle Cloud, Alibaba Cloud, and on-prem, without depending on one provider console.
- Policy evaluation: Evaluate infrastructure resources against defined policies and create violations when assets fail required conditions.
- Framework-aligned checks: Connect failed checks to frameworks such as PCI, HIPAA, NIST, ISO, GDPR, and CIS Benchmarks for AWS, Azure, and GCP.
- Custom governance: Create custom policies for internal rules such as required tags, approved regions, access patterns, and organization-specific control logic.
- Exception and workflow handling: Manage exceptions, route violations, and escalate issues through Jira, ServiceNow, and ServiceDesk integrations.