Why does a cybersecurity program not fully solve privacy risk for ePHI?

A cybersecurity program helps protect ePHI, but privacy risk also comes from how information is collected, stored, shared, and used. That means privacy failures can occur even when security controls are in place. Organisations need controls that address data handling, purpose limitation, user expectations, and governance, not only confidentiality and access control.

Cybersecurity reduces the chance that ePHI is stolen, altered, or exposed through unauthorized access. Privacy risk is broader: it also includes whether the data was collected for a valid purpose, whether people were told how it would be used, whether sharing stayed within expected boundaries, and whether retention or reuse created an unnecessary exposure.

That distinction matters because an organisation can have strong access control, encryption, and monitoring and still create a privacy problem by over-collecting ePHI, using it for secondary purposes, or sharing it too widely internally or with vendors. In other words, security protects the data; privacy governs the legitimacy of the data use.

Where privacy failures happen even when security controls work

Many privacy failures happen in ordinary workflows, not in obvious breaches. Examples include collecting more ePHI than is needed, keeping it longer than the business justification supports, repurposing it without a clear basis, or exposing it to staff who technically have system access but do not need it for the intended task.

They can also arise in analytics, reporting, testing, and support processes. Masked or tokenized data may still be sensitive if it is re-identifiable, and a well-protected system may still leak privacy through broad sharing, weak minimisation, or unclear consent and notice practices. For broader privacy governance, the EU General Data Protection Regulation (GDPR) is a useful reference point because it separates security of processing from principles such as purpose limitation, data minimisation, and privacy by design.

Privacy risk also appears when organisations assume that a security program alone resolves governance. Security controls answer questions like “who can access this?” and “can we detect abuse?” Privacy controls must also answer “should we have this data at all?”, “who may use it?”, and “for what purpose?”. The NIST Privacy Framework is a useful companion because it centres data processing choices, contextual integrity, and privacy risk management rather than only confidentiality.

Why ePHI is a special case

ePHI sits at the intersection of healthcare operations, regulated handling, and cyber protection. The confidentiality requirement is important, but it is not the whole problem. ePHI can be properly encrypted, access-controlled, and logged while still being handled in a way that creates privacy harm, such as unnecessary disclosure, excessive internal circulation, or use outside the patient or treatment context.

That is why a cybersecurity program is necessary but not sufficient. It contributes controls for access restriction, detection, and resilience, but privacy also depends on policies, data governance, role boundaries, vendor handling, and lifecycle decisions about collection, retention, disclosure, and disposal. Under GDPR, the distinction between security controls and lawful processing obligations is explicit, and the same practical logic applies in many regulated healthcare environments even where GDPR is not the governing law.

Risk and Threat Considerations

When privacy is treated as a subset of cybersecurity, organisations tend to miss high-probability failure modes that do not look like classic breaches. The result is exposure through over-collection, excessive sharing, weak purpose controls, and lingering datasets that remain sensitive long after the original business need has passed.

Failure mechanism: Security controls can block unauthorized access while still leaving authorised but excessive access, reuse, or disclosure paths intact. That creates privacy risk through legitimate workflows, third-party processing, or poor governance rather than through a single obvious intrusion.

Impact: The organisation can suffer regulatory findings, patient trust damage, internal misuse, and downstream breach amplification if a later compromise exposes data that should never have been retained or broadly distributed in the first place.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while GDPR defines the regulatory obligations.

Framework	Control / Reference	Relevance
GDPR	A.5.15 — Data protection by design and by default	ePHI privacy risk depends on purpose, minimisation, and design choices beyond security.
	A.5.34 — Privacy and protection of PII	Privacy risk for ePHI is directly about governed processing of sensitive personal data.
Recommendation — Build privacy controls into ePHI workflows so collection, sharing, and retention stay limited to purpose. Map ePHI handling to privacy obligations and document lawful use, sharing, and retention.
NIST SP 800-53 Rev 5	PM-18 — Privacy Program Plan	The question is about why privacy needs governance beyond cybersecurity controls.
	AR-2 — Privacy Impact and Risk Assessment	Privacy risk persists even when security is strong, so processing risk must be assessed separately.
	AC-6 — Least Privilege	Authorised access can still create privacy exposure when permissions are broader than purpose.
Recommendation — Define a privacy program that covers collection, use, disclosure, and retention decisions. Assess ePHI processing paths for minimisation, secondary use, and disclosure risk. Restrict ePHI access to the minimum roles and workflows needed for the intended purpose.

Practitioner Guidance

What to verify: Confirm that your ePHI program has explicit controls for data minimisation, purpose limitation, retention, sharing, and deletion, not only access control and encryption. If those decisions are undocumented, privacy risk is probably being managed informally.

Decision rule: If a process needs ePHI to operate but cannot clearly justify the collection or downstream sharing, treat it as a privacy design issue, not just a security hardening issue. If the issue is re-identifiability, secondary use, or vendor disclosure, the fix usually sits in governance and data handling, not in the SOC.

Practitioner takeaway: A strong cybersecurity program lowers exposure to compromise, but privacy risk only falls when the organisation also controls why ePHI exists, how long it stays, who may use it, and whether that use remains legitimate.