Health organisations should treat PHI protection as a layered control problem, not a single product problem. Encrypt stored data and backups, use secure messaging and transport for data in motion, and enforce multifactor authentication and access controls for data in use. Pair those controls with monitoring so teams can detect when PHI appears in the wrong system, channel, or storage location.
Protecting PHI by data state: rest, motion, and use
PHI protection works best when organisations match the control to the data state, because each state fails in a different way. data at rest is exposed through storage compromise and backup leakage, data in motion through interception or misdirected transmission, and data in use through overbroad access, weak session control, and poor visibility into who can read or export it.
For stored PHI, encryption is necessary but not sufficient. The practical question is whether keys, backups, replicas, exports, and test copies are governed as tightly as the primary system. Organisations that leave PHI in analytics stores, shared folders, unmanaged exports, or recovered backups often create the real exposure even when the source database is encrypted. The same logic applies to secrets and credentials that unlock storage systems or application access, because protection breaks down as soon as those controls are reused too broadly.
For PHI in motion, the aim is to preserve confidentiality and integrity across every route the data can take, including application-to-application transfers, messaging workflows, remote access, and third-party integrations. A secure transport layer only helps if the destination, certificates, and trust relationships are also controlled. If a workflow sends PHI to the wrong recipient, the problem is no longer just interception risk, it is also routing, authorisation, and data handling failure.
For PHI in use, organisations should assume the data is most vulnerable to misuse once a legitimate session exists. Multifactor authentication, strong session controls, role-based access, and privileged access restrictions reduce the chance that a compromised account can freely browse or extract records. Monitoring should focus on unusual access patterns, unexpected bulk reads, and PHI appearing in systems that should never store it, because misuse is often visible first as abnormal placement or movement rather than a confirmed breach.
Risk and Threat Considerations
PHI control failures usually arise when organisations treat encryption as the end state instead of one layer in a larger access and handling model. The biggest risks are silent leakage into backups, logs, exports, test environments, and third-party channels, plus excessive access that turns a single account compromise into broad disclosure.
Failure mechanism: Sensitive data becomes exposed when storage protections, transport protections, and access protections are not aligned with the actual handling path, especially where replicas, integrations, or support workflows bypass normal controls.
Impact: PHI can be disclosed, altered, or moved into systems with weaker controls, creating privacy harm, compliance exposure, incident response burden, and difficult-to-trace downstream redistribution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while GDPR and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 3 — Data Protection | Directly governs PHI protection across storage, transfer, and controlled handling. |
| CIS Control 5 — Account Management | PHI in use depends on limiting and reviewing who can access records and systems. | |
| CIS Control 6 — Access Control Management | Least-privilege access is central to preventing PHI misuse once data is in use. | |
| Recommendation — Encrypt and classify PHI, then enforce handling controls across storage, transport, and use. Restrict account access to PHI to approved users and remove unused access promptly. Apply least privilege to PHI systems and review access paths for excessive permissions. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Covers protecting confidentiality and integrity of data at rest and in transit. |
| PR.AA — Identity Management, Authentication and Access Control | Controls access to PHI when it is being used by authenticated users and systems. | |
| DE.CM — Continuous Monitoring | Monitoring is needed to detect PHI in unexpected systems, channels, or storage locations. | |
| Recommendation — Apply data security safeguards that protect PHI throughout storage and transmission. Require strong authentication and access control before PHI can be read or exported. Monitor for anomalous PHI access, movement, and storage outside approved locations. | ||
| GDPR | Article 32 — Security of Processing | Requires appropriate technical and organisational measures for protecting personal data like PHI. |
| Recommendation — Implement encryption, access controls, and resilience measures proportionate to PHI risk. | ||
| ISO/IEC 42001:2023 | AI management system | Not used |
Practitioner Guidance
What to verify: Confirm that PHI is encrypted wherever it is stored, that backups and replicas follow the same protection standard, and that decryption keys are separated from the data they protect. Then test whether transfer paths, application integrations, and file exchanges preserve confidentiality end to end, rather than only at one hop.
What good looks like: Access to PHI is limited to named business roles, privileged access is tightly bounded, and monitoring can show where PHI exists, who touched it, and whether it moved to an unauthorised system. In practice, the strongest control is not just encryption, but provable control over placement, access, and reuse.
Practitioner takeaway: If you cannot account for where PHI is stored, transmitted, and opened, you do not yet have a complete protection model, even if encryption and authentication are in place.
Related resources from NHI Mgmt Group
- How should healthcare organisations govern access to PHI across business associates?
- How should healthcare organisations govern access to PHI across portals and third-party apps?
- How should healthcare organisations implement PHI compliance across SaaS and GenAI tools?
- Why do healthcare organisations need PHI redaction before sharing data for collaboration or support?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
