I treat PCI compliance as a payment-security requirement - not proof that patient data and care are safe. My starting point: test vendor access, shared accounts, and clinical recovery separately, even when payment systems pass assessment.
Why? A study of 374 healthcare ransomware attacks found that 44.4% disrupted care delivery.[5] Keeping payments online does not keep an EHR, pharmacy, or imaging system running.
Here’s what I focus on:
- Check the boundaries: Test PCI scope, segmentation, and access paths between payment and clinical systems.
- Protect patient data: Review third-party vendor security risks, subcontractors, shared identities, and medical-device connections.
- Prove recovery works: Test isolated backups and rehearse clinical downtime against recovery targets. Plan for at least four weeks without digital services.[1]
- Assign responsibility: Rank gaps by patient harm, name owners, and track deadlines and test results in Censinet RiskOps™.
My bottom line: <u>a passed assessment is not a recovery test</u>. I want proof that controls protect care - not just payment processing.
Beyond PCI Compliance: Protect Patient Care in 4 Steps
Where Healthcare Cyber Risks Remain
PCI protects the payment environment - not the rest of the hospital. It may validate the payment boundary, but it does not measure patient harm or readiness to recover. The risk depends on the system.
PCI DSS applies to systems within the CDE, as well as systems connected to it or capable of affecting its security. The table below explains that boundary, not hospital-wide protection.
| Asset or function | PCI DSS coverage when in scope | What remains at risk |
|---|---|---|
| PHI | Systems handling cardholder data or affecting CDE security | Patient records can still be stolen, altered, or unavailable. |
| Care continuity | Clinical systems affecting CDE security | EHR, imaging, laboratory, and pharmacy outages can interrupt care. |
| Medical devices | Connections to or effects on the CDE | Unsupported devices may expose clinical networks or interrupt treatment. |
| Vendor access | Vendor services and connections affecting the CDE | Clinical support accounts can expose PHI and connected applications. |
| Identity systems | Credentials and identity services controlling CDE access | Shared privileged identities can enable movement between environments. |
| Backups | Backups containing cardholder data or supporting CDE security | Clinical backups may be reachable by ransomware or fail during restoration. |
These gaps can lead to medication errors, diagnostic delays, and unsafe downtime workarounds. Compliance does not settle questions of clinical risk: the most dangerous exposures affect care delivery, not payment processing.
Ransomware, compromised vendor access, and failed recovery can turn those gaps into disruptions to patient care.
Ransomware Can Halt Care While Payments Stay Online
Hypothetical scenario: Ransomware disables a regional hospital’s EHR, imaging archive, and pharmacy workflows while its isolated payment environment remains unaffected. Clinicians lose access to medication histories and allergy checks. Imaging delays hold up diagnoses, and pharmacy dispensing slows. Paper medication records must be reconciled carefully to avoid missed or duplicate doses; downtime forms, communication channels, and staffing arrangements must already be tested.
Having backups does not prove that clinical systems can recover. Test whether identity services, DNS, storage, EHR databases, and pharmacy and laboratory interfaces can return in the order care requires. HHS recommends isolating backups, verifying their integrity, and regularly testing restoration.[3] A study of 374 healthcare ransomware attacks found that 44.4% disrupted care delivery, including downtime, canceled care, and ambulance diversion.[5]
Compromised Vendors Can Reach PHI and Clinical Systems
Hypothetical scenario: An attacker takes over a support vendor’s account and uses excessive privileges to query PHI in a clinical application. Persistent remote access provides a path toward connected systems. The payment environment remains unaffected, but the hospital may face PHI exposure, clinical disruption, forensic uncertainty, and breach-notification decisions.
Check who owns that access, whether MFA is enforced, and whether permissions expire after approved work. Include fourth parties, such as cloud hosts and subcontractors. Set incident-notification deadlines and evidence requirements, and assign responsibility for determining whether PHI was exposed.
Excluding systems from scope does not remove risk if they still share identities, connections, or recovery paths.
Out-of-Scope Systems Can Still Create Attack Paths
Look closely at shared identities, administrative tools, APIs, cloud connections, medical device security risks, and backup infrastructure.
A backup server that can restore payment systems may affect CDE security even if it does not store card data.
An overlooked connection can invalidate a scope exclusion. Even a valid exclusion does not establish clinical safety. Review data flows and admin access, then test segmentation from vendor, administrator, API, and device paths.
sbb-itb-535baee
Check PCI Scope and Assess Clinical Risk
Test whether those boundaries hold in practice.
Use PCI scope to inform risk assessment - not to define its limits. Test PHI exposure, vendor access, and recovery risk separately. Map both the payment and clinical-risk environments. Then have leaders from security, clinical operations, biomedical engineering, privacy, procurement, and business continuity review both maps. Give each finding a technical owner and a clinical owner.
Test Segmentation and Identity Separation
Check network and data-flow diagrams against firewall rules, routing, cloud security groups, and observed traffic across payment and clinical environments. Include every system that touches the CDE.
Trace what an ordinary workforce account, a vendor account, and a service account can actually access across both environments. Check privileged-account separation, API credentials, and remote administration - not just network boundaries. Record the paths tested, the evidence collected, and any exceptions.
Map PHI, Vendor Access, and Recovery Dependencies
Create a record for each out-of-scope PHI repository and critical clinical service. Link each record to its owner, interfaces, vendor privileges, and recovery dependencies. Check procurement records and access logs for missing subcontractors and connections.
Request evidence that backups are isolated, immutable where appropriate, and successfully restored in a clean environment. Verify that monitoring can detect compromised access and that responders can contain it without disrupting essential care.
Rank Risks by Patient Harm and Recovery Difficulty
Rank findings by patient harm, care disruption, PHI exposure, exploitability, shared dependencies, and recovery difficulty. Pay particular attention to shared services whose failure could disable several clinical functions at once.
Clinical owners should set recovery time objectives (RTOs) - the acceptable time to restore service - and recovery point objectives (RPOs) - the acceptable amount of data loss. Compare those limits with test results, not backup schedules.
Give every material finding an accountable owner, a remediation deadline, interim controls, and a documented residual-risk decision. Escalate findings when tested recovery takes longer than clinical tolerances allow or relies on untested manual workarounds. Keep required PCI remediation on track, but don't let compliance severity alone decide which patient-care risks get attention first.
Close Gaps Across Payment and Clinical Systems
Limit Access and Protect Clinical Systems
After ranking residual risk, close the easiest-to-exploit paths to care-critical services first. Don’t put every asset on the same schedule. Address exposure beyond PCI scope, including clinical access, vendor connections, and recovery failures.
Allow connections only for documented business needs. Revalidate segmentation after changes to firewalls, cloud systems, routing, or remote access. Extend phishing-resistant MFA, individual accounts, least privilege, and time-limited privileged access beyond payment systems. Assign owners to service accounts, rotate secrets, and revoke access when roles or contracts end.[7]
Link asset inventories to vulnerability management and endpoint detection and response (EDR) coverage. For unsupported medical devices, document network restrictions, approved maintenance paths, monitoring, and replacement plans. Coordinate changes with biomedical engineering and clinical owners so security fixes don’t interrupt treatment.
Control Vendor Access and Test Care Recovery
Classify vendors by PHI access, connectivity, privilege, and care dependency. Match security evidence requirements to each vendor’s risk, and require contracts with clear incident-notification deadlines and cooperation duties. Replace standing access with named accounts, MFA, approved access windows, monitored sessions, and automatic expiration. Reassess access when integrations, ownership, or services change.[6]
Treat recovery as a clinical drill, not just a technical restore. Protect backup-management credentials separately from production accounts. Restore care-critical services and their interfaces. Then have clinicians rehearse patient identification, medication administration, orders, and emergency communications against clinical RTO/RPO targets. Record actual recovery times, data-integrity issues, and failed workarounds, and use those findings to assign corrective actions.
Track Assessments and Remediation in Censinet RiskOps™
Use Censinet RiskOps™ to centralize third-party and enterprise assessments, evidence, remediation owners and deadlines, benchmarking, and risk visualization. Use Censinet AITM for vendor-evidence summaries and assessment reports, and Censinet AI for evidence validation, task routing, and governance workflows.
Require human review of material cybersecurity and patient-safety decisions. Close findings only after technical validation, and keep exceptions and overdue actions visible to accountable leaders.
Conclusion: Assign Owners and Act on Residual Risk
Use the matrix below to give each highest-ranked residual risk a named owner and proof that controls work. Set remediation deadlines and recovery tests for every finding.
| Exposure | Attack path | Consequence | Safeguard | Validation evidence | Accountable owner | Priority |
|---|---|---|---|---|---|---|
| Third-party ransomware | Common business associate compromise | Delayed emergency care; ambulance diversion | 4-week continuity plans [1] | Downtime drills and cyberattack exercises | Executive sponsor | Critical |
| Compromised vendor access | Third-party system-management access | PHI loss and care disruption | Third-party vendor risk management and BAA security terms | Annual control validation and testing | Third-party risk lead | High |
| Shared identity/system management | Shared identity and admin-tool abuse | Care disruption across clinics and emergency departments | Complete vendor and subcontractor inventory | Periodic technical and procedural reviews | IT/security lead | High |
Test whether a payment admin account or vendor account can reach a clinical service. Assign an owner and deadline to close each gap, then run a recovery drill with clinical, emergency preparedness, and vendor teams.
FAQs
How can we uncover clinical risks our PCI assessment missed?
Look beyond the cardholder data environment (CDE). Map how payment systems, patient portals, billing applications, and medical devices connect. Use passive discovery to avoid disrupting devices.
Pair compliance reviews with continuous risk assessments that focus on patient safety and clinical continuity. Use red team exercises, penetration testing, and tabletop drills to find gaps. Check vendor security, and make sure IT, clinical, and vendor teams understand shared controls, dependencies, and incident response handoffs.
What evidence proves vendor access is properly restricted?
Don’t rely on self-attestation alone. Review identity and access management logs, verify multifactor authentication for every remote session, and confirm least-privilege permissions. Check records to ensure stale accounts were removed and access was restricted to approved, time-bound maintenance windows.
Audit network segmentation boundaries and verify that vendor access ends immediately when contracts expire or vendors are offboarded.
How do we set recovery targets that protect patient care?
Set recovery time objectives for every critical system by linking framework requirements to attack paths and their effects on patient safety [1]. Document measurable recovery targets and procedures. Test them at least annually through simulations with IT and clinical leadership [1][2][3].
Use offline, immutable backups to keep data available if primary systems are compromised [4][3]. Establish clinical continuity procedures so teams can maintain patient care during system outages [2][3].
