Healthcare Data Security

What is healthcare data security?

Healthcare data security is the set of controls that protect patient data where it is stored, copied and moved: an inventory of every data store, encryption with well-managed keys, tight access and audit logging on databases and files, tested backups, and de-identified copies for analytics. It sits below application security and covers data the application never touches.

The distinction matters because many reads of patient data never pass through the application. An engineer runs a query in production, a reporting tool connects with a service account, or a nightly job copies a table to a warehouse. Each of those paths needs its own controls.

Where does patient data actually live?

Patient data lives in more places than the architecture diagram admits. The first task is an inventory that lists every store, what it holds, who owns it and how data gets in and out.

Build the inventory from the infrastructure, not from memory. Cloud account listings, database catalogs, storage bucket lists and integration engine channel configurations show what exists. Interviews then explain why each store is there.

• Primary stores: The application database, document storage and the EHR integration staging tables.
• Derived stores: Warehouses, reporting marts, search indexes and caches built from the primary data.
• Copies: Backups, snapshots, replicas in another region and restored copies left behind after a test.
• Byproducts: Application logs, error trackers, message queues and dead-letter queues that hold full payloads.
• Exports: CSV files, scheduled reports, partner feeds and anything that leaves by SFTP or email.

Give each store a classification. A simple scheme is enough: identified patient data, de-identified or limited data, internal business data and public data. The classification decides which controls apply, so a store without one is treated as identified patient data until someone proves otherwise.

Keep the inventory as a maintained record with an owner, not a one-off spreadsheet. A new store should not reach production without an entry, and a pipeline check that compares cloud resources against the inventory catches the ones that slip through.

What does HIPAA say about encrypting stored data?

HIPAA treats encryption as addressable, not required. Under 45 CFR 164.312, encryption and decryption of ePHI at rest and encryption in transmission are addressable implementation specifications, which means a regulated entity implements them or documents why an equivalent measure is reasonable, while audit controls are a required standard.

In January 2025 HHS published a proposed rule that would make encryption and multi-factor authentication required. It is a proposal, not the current rule. Encrypting stored data and using MFA for administrators are still good practice today.

There is also a strong practical reason to encrypt. HHS breach notification guidance treats protected health information encrypted to its standard as secured, so the loss of properly encrypted data, with the keys kept separate, falls under the breach notification safe harbor.

Know what each layer of encryption protects against. Disk or volume encryption stops someone who takes the physical media. It does nothing against an attacker who signs in with valid database credentials, because the database decrypts the data for every authorized query. Field-level encryption of the most sensitive columns, such as identifiers or notes, narrows that gap for the fields that need it.

Who should hold the encryption keys?

Keys should sit in a managed key service, separate from the data they protect, under a smaller group of administrators than the data itself. Whoever can read both the data and its key can read everything, so that group should be as small as the work allows.

Most cloud stores use envelope encryption. Each object or table is encrypted with a data key, and the data key is encrypted with a key held in the key management service. Rotating the outer key does not require re-encrypting every record, which makes regular rotation practical.

• Provider-managed keys: The simplest choice. The cloud provider creates and rotates the key, and access follows the storage permissions.
• Customer-managed keys: The team creates the key in its own key service account, controls rotation and can revoke access to stop all decryption.
• Per-tenant keys: A multi-tenant product gives each customer organization its own key, so one customer's data can be cut off or deleted by destroying a key.
• External key stores: Keys held outside the cloud provider, used when a contract demands it. They add an availability dependency that must be tested.

Log every use of a key, not only every change to it. A spike in decrypt calls from an unexpected role is one of the clearest signs that someone is reading data in bulk.

Access and audit on the data stores

Direct access to a data store should be rare, named and recorded. Applications connect with service accounts that can reach only their own tables, and people get time-limited access for a stated reason.

Separate roles by job. The application role reads and writes its own schema. The reporting role reads a curated view, not the raw tables. The migration role runs only during a deployment. No shared administrator password sits in a wiki.

For people, use just-in-time access: an engineer requests read access to production for a ticket, a second person approves it, and the grant expires on its own. Emergency access works the same way with approval after the fact, so a night-time incident is not blocked by an empty approval queue.

Turn on query and object access logging in the store itself, and ship the logs to an account the database administrators cannot alter. Review them on a schedule for bulk reads, off-hours access and reads by accounts that normally only write.

How do you prove a backup will restore?

You prove it by restoring it. A backup job that reports success shows that data was copied, not that the team can rebuild a working system from it in the time the business needs.

Start with two numbers the business sets: how much recent data it can afford to lose, and how long the system can be down. Those targets decide backup frequency, whether replicas are needed, and how much of the restore must be automated.

Keep at least one backup copy in a separate account with its own credentials and deletion protection. An attacker who takes over the production administrator account can delete or encrypt every copy that account can reach, so a backup inside that reach is not a safe copy.

Run restore tests into an isolated environment on a set schedule. Record how long the restore took, which checks proved the data was complete, and what broke. Then destroy the restored copy, because a forgotten test restore is another full store of patient data.

When should analytics use de-identified data?

Use de-identified data whenever the analysis does not need to reach a specific patient. Most trend reports, model training sets and product analytics fall into that group, and removing identifiers shrinks the number of places that hold identified data.

HHS guidance describes two methods under 45 CFR 164.514(b): Safe Harbor, which removes specified identifiers and requires no actual knowledge that the rest could identify a person, and Expert Determination, in which a qualified expert finds the risk of re-identification very small. Data de-identified by either method is no longer protected health information.

Build de-identification as a pipeline step with tests, not a manual export. The step drops or generalizes direct identifiers, shifts or truncates dates where the method requires it, and checks free text, which often carries names and record numbers inside notes.

Keep any re-identification key in the identified zone, never alongside the de-identified copy. If analysts need to contact patients from a finding, that request goes back through the identified system with its own access controls.

Data loss paths to close

Data usually leaves through ordinary features rather than dramatic attacks. This checklist names the paths to close or monitor before a security review finds them.

• 1. Production copies in test: Refreshing a staging database from production puts real patient data under weaker controls. Use synthetic or de-identified data instead.
• 2. Payloads in logs: Error trackers and debug logs capture full requests. Mask fields before they are written, and keep the audit trail as a separate record.
• 3. Dead-letter queues: Failed integration messages pile up with full clinical content and no retention limit.
• 4. Unlisted exports: Scheduled reports and partner feeds run for years after the partner relationship ends.
• 5. Public storage links: Pre-signed URLs or open buckets meant for a single file transfer stay valid.
• 6. Analytics and tracking tags: Page tags on signed-in screens send identifiers and health details to third parties.
• 7. Orphaned snapshots: Disk and database snapshots survive the deletion of the system they came from.
• 8. Retired hardware: Laptops and drives leave the building without verified sanitization.

Assign each path an owner and a control: a block, a monitor or an accepted risk written into the risk analysis. An accepted risk with a name and a review date is far better than a path nobody has looked at.

How Agnotic can help

Data security work stalls when nobody owns the whole picture across application, cloud and data teams. Agnotic Technologies fills that role for the client through fractional CTO leadership: building the data store inventory, choosing key management patterns, designing database roles and just-in-time access, and setting up restore tests that produce evidence.

Agnotic engineers also build the pieces: de-identification pipelines with tests, log masking, export controls and the monitoring that flags bulk reads, so the controls in the risk analysis match what runs in production.

Sources

• 45 CFR 164.312: Technical safeguards
• Federal Register: HIPAA Security Rule proposed rule (6 January 2025)
• HHS: Breach notification guidance on unsecured protected health information
• HHS: Guidance on de-identification of protected health information