Healthcare app hardening
Encryption, key management, and access control for a live product.
PHI Data Security
PHI data security and encryption, engineered from the first commit
We secure protected health information end to end (encryption at rest and in transit, KMS-backed key management, and de-identification via Safe Harbor or Expert Determination) designed into your architecture, not retrofitted before an audit.
HIPAA-ReadyRole-Based AccessKMS Key ManagementAudit Logged
Trusted by global innovators
What is PHI data security?
PHI data security is the set of engineering controls that keep protected health information confidential, intact and available wherever it is stored, processed or sent: encryption at rest and in transit, managed keys, access control, audit logging and de-identification for secondary use. Startups and enterprise product teams that handle PHI for covered entities need it.
The HIPAA Security Rule treats encryption as addressable, but unencrypted PHI is how most breaches become reportable. We build envelope encryption with managed keys (AWS KMS, GCP Cloud KMS or Azure Key Vault), automatic rotation, field-level protection and de-identification pipelines.
What it is
Protecting PHI through its whole lifecycle
PHI data security is the set of controls that protect protected health information wherever it lives: encryption at rest and in transit, managed key custody, de-identification for secondary use, access control, and audit logging.
Done right, it satisfies the HIPAA Security Rule, survives a SOC 2 audit, and gives you the evidence trail you need after any incident. We architect it in from the start.
A defense-in-depth architecture for PHI
Encryption, key management, de-identification, access control, and audit logging composed into one architecture you can defend to auditors and to your board.
What do we build into a PHI security posture?
Each control pairs a protection with the standard or mechanism that backs it.
Encryption at Rest & in Transit
AES-256 encryption at rest and TLS 1.2+ in transit across every service, with envelope encryption so data keys are themselves encrypted by a managed root key, no plaintext PHI on any disk or wire.
KMS Key Management & Rotation
Centralized key management via AWS KMS, GCP Cloud KMS, or Azure Key Vault, with least-privilege key policies, automatic rotation, and separation of duties so no single actor can both access data and control its keys.
De-identification: Safe Harbor & Expert Determination
De-identification pipelines that strip the 18 Safe Harbor identifiers, or an Expert Determination approach with documented statistical risk analysis, so analytics, ML, and lower environments never handle live PHI.
Access Control & Audit Logging
Role-based and attribute-based access control, MFA, and tamper-evident audit logs of every PHI access: the record you need for HIPAA accounting-of-disclosures and incident forensics.
Field-Level & Tokenized Protection
Application-layer encryption and tokenization for the highest-sensitivity fields (SSN, genomic, behavioral health), so a database compromise doesn't hand over the crown jewels.
Secrets, Backups & Incident Readiness
Managed secrets, encrypted and tested backups, breach-notification runbooks, and BAA governance across every subprocessor: HITECH-aligned readiness before an incident, not after.
Where it applies
Where does PHI data security apply?
SOC 2 / HITRUST readiness
Control implementation and evidence collection for audit.
Analytics de-identification
Safe Harbor or Expert Determination pipelines for BI and ML.
Enterprise security review
Meeting the security questionnaires that gate provider deals.
Cloud migration security
PHI-safe migration to AWS, GCP, or Azure with managed keys.
Incident response prep
Runbooks, logging, and forensics readiness before an incident.
Why is PHI security its own workstream?
Encryption and key management are the controls regulators and enterprise buyers scrutinize first: we build them to be provable.
AES-256
encryption at rest, TLS 1.2+ in transit
18
Safe Harbor identifiers removed in de-identification
Compliance-First Healthcare App Development Services Backed by Global Standards
15-Minute Scoping Call01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Multi-tenant keys
How should encryption keys be planned for a multi-tenant product?
Encryption keys for a multi-tenant product come down to six decisions: shared or per-tenant keys, who manages them, the cryptoperiod, a validated module or dedicated HSM, deleting a tenant by destroying its keys, and who reads key usage logs. Agnotic Technologies settles each one first.
| Decision | Options | When each fits |
|---|---|---|
| One key per tenant or a shared key | A data key per tenant under its own key, or one key for all tenants with tenant IDs in every row | Per-tenant keys fit when enterprise buyers ask for isolation or deletion on exit; a shared key fits a small product with no such demands yet |
| Provider-managed or customer-managed keys | Keys created and held in your cloud KMS, or keys the customer controls in their own account and can revoke | Customer-managed keys fit enterprise health systems that require control of their own keys; provider-managed keys fit everyone else |
| Cryptoperiod per key type | A defined period for root keys, data keys and signing keys, with rotation or re-encryption at its end | Every product needs one written down; NIST SP 800-57 Part 1 gives the method for setting it by key type |
| Validated module or dedicated HSM | A cloud KMS backed by FIPS 140-3 validated modules, or a single-tenant hardware security module | A validated KMS fits most products; a dedicated HSM fits contracts that require single-tenant hardware |
| Deleting a tenant by destroying its keys | Destroy the tenant's key so its data and backups can no longer be read, or delete records one by one | Key destruction fits per-tenant keys and data spread across backups; record deletion fits a shared key |
| Who can read key usage logs | Your security team only, or the tenant's own security team through an export or a feed | Sharing logs fits customer-managed keys and buyers with their own security operations team |
Envelope encryption, rotation and separation of duties are covered in the key management card above; this table is about how those keys are divided between tenants.
Standards we build against
Which standards does PHI security follow?
HIPAAHITECHSOC 2HITRUSTNISTAES-256
Our Process
From data inventory to provable controls
We treat PHI security as an auditable engineering program: map the data, protect it in layers, and prove it holds.
1.
PHI Data Mapping
We inventory where PHI lives, flows, and rests across your systems and subprocessors: you cannot protect what you haven't mapped.
Know your data
2.
Encryption & Key Design
Encryption at rest and in transit, envelope encryption, and KMS-backed key management with least-privilege policies and rotation.
Keys under control
3.
De-identification & Access
Safe Harbor or Expert Determination de-identification pipelines, RBAC/ABAC, MFA, and tamper-evident audit logging.
Least privilege
4.
Validate & Monitor
Penetration testing, control validation against HIPAA and SOC 2, continuous monitoring, and incident-response runbooks.
Provable & audit-ready
Facts and sources
Which rules and standards guide PHI data security?
The HIPAA rules that define PHI safeguards and the NIST publications behind the key table, each linked to its primary source.
NIST SP 800-57 Part 1 Rev. 5 gives general guidance and best practices for managing cryptographic keying material, including the protection each type of key requires and how to provide it.
Source: NIST SP 800-57 Part 1 Rev. 5 (csrc.nist.gov)FIPS 140-3 sets security requirements for cryptographic modules at four increasing levels, covering areas such as roles, services and authentication, physical security, sensitive security parameter management and self-tests.
Source: FIPS 140-3 (csrc.nist.gov)The HIPAA Security Rule requires administrative, physical and technical safeguards for electronic protected health information.
Source: 45 CFR Part 164 Subpart C (eCFR)HIPAA allows two ways to de-identify health data: expert determination, or the safe harbor method, which removes 18 categories of identifiers.
Source: 45 CFR 164.514(b) (eCFR)
Featured case study
Read Case StudyLera Health: compliant women's health platform
Lera Health handles sensitive biomarker and hormone data on a privacy-first data layer we built end to end: the same encryption, key-management, and access-control discipline that defines our PHI security work.
Why Partner With Us
15-Minute Scoping CallSecurity that holds up under audit and after an incident
We build PHI protection as a first-class engineering program, with the evidence trail auditors and enterprise buyers ask for.
Compliance-First by Default
HIPAA, HITECH, and SOC 2 controls designed into architecture from sprint one: never bolted on before an audit.
Provable Controls
Encryption, key policies, and audit logs configured to produce the evidence you need for OCR, SOC 2, and enterprise security reviews.
Defense-in-Depth Engineering
Layered protection (encryption, key management, de-identification, and access control) so no single failure exposes PHI.
Sensitive-Data Depth
Experience protecting reproductive, behavioral, and genomic data where the privacy stakes are highest.
Frequently Asked Questions
No. Encryption at rest and in transit is foundational, but HIPAA requires access controls, audit logging, key management, and administrative safeguards too. We build defense in depth (encryption, KMS-backed keys, RBAC/ABAC, and tamper-evident logging) so a single failure never exposes PHI, and you have the evidence trail an audit requires.
Safe Harbor de-identification removes the 18 specified identifiers and is deterministic and simple to defend. Expert Determination uses a qualified statistician to certify that re-identification risk is very small, which lets you retain more data utility. We implement either: Safe Harbor for straightforward cases, Expert Determination when analytics needs richer data.
Basic encryption you can enable yourself; a defensible, auditable program is harder. The gap is usually key management, de-identification, and the evidence trail: the parts auditors scrutinize. We bring proven patterns and the audit artifacts so you reach a provable posture faster than building the expertise from scratch.
Yes. We work across AWS, GCP, and Azure, integrate with your existing services, and extend BAA governance to subprocessors. Encryption, KMS key policies, and audit logging are applied consistently across your stack rather than added service by service.
Cost follows scope: the number of systems and data stores that hold PHI, the integrations and subprocessors in the data path, whether de-identification pipelines are needed, and the audit target you are preparing for. We scope it against your architecture in a scoping call.
It depends on how many services and data stores handle PHI, how much of the encryption and key management already exists, whether analytics needs de-identified data, and the evidence your auditor asks for. SOC 2 Type II readiness also depends on the observation window your auditor sets.
Yes. A first release can be scoped to one workflow, for example encrypting and access-logging the PHI in one service with managed keys, and then extended to the rest of your stack once that pattern is proven.
AI tools help our engineers draft code and tests, but a person reviews every change, and it passes the same automated tests and security checks as any other code. Which tools may see your code or data is agreed with you at the start.
Ready to prove your PHI is secure?
Tell us your stack and your audit target. We'll return a phased security plan covering encryption, key management, de-identification, and the evidence trail.
contact@agnotic.com
Partnerships
contact@agnotic.com