---
cuppy_hub: aws
cuppy_path: examples/healthcare-master-data/04-security-and-hipaa.md
cuppy_section: docs
cuppy_doc: 5ZQZ-MGHG
cuppy_doc_uuid: b11bd750-022b-409b-bd17-0ade25f8d932
cuppy_permalink: https://cuppy.io/aws/d/5ZQZ-MGHG
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/aws/docs/examples/healthcare-master-data/04-security-and-hipaa
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: df2670770ac8aaa2cc1a8130dfd0fb07f87ad106dbe378a83f22dc9a610eb8e0
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Security and HIPAA for a native healthcare master

## The contract comes first

Nothing else here matters without the agreement. "The Business Associate Addendum (BAA) is an AWS
contract that is required under HIPAA rules to ensure that AWS appropriately safeguards protected
health information (PHI)." It is self-service: review and accept it in AWS Artifact.

The eligible services reference carries the operative restriction verbatim:

> "If you are a Covered Entity or Business Associate as defined by the Health Insurance Portability
> and Accountability Act of 1996 (as amended, "HIPAA"), you agree not to use these HIPAA Eligible
> Services for any purpose or in any manner involving Protected Health Information (as defined by
> HIPAA) without first entering into an AWS business associate agreement."

Two corrections to common assumptions follow from the same pages.

**There is no certificate.** "There is no HIPAA certification for a cloud service provider (CSP)
such as AWS." Eligibility is contractual and architectural, so "HIPAA certified on AWS" cannot be
true of anyone.

**Eligibility constrains where PHI goes, not which services you may use.** "Customers may use any
AWS service in an account designated as a HIPAA account, but they should only process, store, and
transmit protected health information (PHI) in the HIPAA-eligible services defined in the BAA."

One archived source to avoid, in both forms. The HTML edition of "Architecting for HIPAA Security
and Compliance on Amazon Web Services" now returns only an archive notice pointing to the HIPAA
Eligible Services Reference. The older PDF still serves the full text, watermarked as archived — so
it looks current and is not — and other AWS pages, the Audit Manager HIPAA framework page included,
still link to that PDF. Cite the reference.

## Eligibility, verified service by service

Every row below was confirmed by verbatim transcription of the relevant band of the eligible
services reference on 2026-10-21 — A to C, D, Elastic to FSx, Glue to Lambda, Macie to Step
Functions, and T to the end. "Listed" means the name appears as its own entry; bracketed caveats
are reproduced.

| Service | Status on the page | Note |
| --- | --- | --- |
| AWS Entity Resolution | Listed, no bracketed exclusion | C2 |
| AWS HealthLake | Listed; its own docs say "This is a HIPAA Eligible Service" | C3 |
| AWS Glue | Listed; Glue DataBrew listed separately | C1 |
| AWS Audit Manager | Listed | C4 |
| AWS Clean Rooms | Listed | C5 |
| Amazon DataZone | Listed | C6 |
| Amazon VPC | Listed as Amazon Virtual Private Cloud (VPC) | C7 |
| Amazon SageMaker AI | Listed, four-part exclusion | C8 |
| Amazon RDS | Listed, engine restriction | C8 |
| Amazon EventBridge | Listed, "[formerly Amazon Cloudwatch Events]" | |
| AWS Security Hub | Listed as AWS Security Hub CSPM | |
| Amazon Macie | Listed | S3-scoped, below |
| AWS Backup | Listed | Gap, doc 06 |

Also listed as their own entries: S3, KMS, Lake Formation, Athena, Redshift,
DynamoDB, Aurora, Step Functions, Lambda, SQS, SNS, Kinesis Data Streams and Firehose, MSK,
CloudTrail, CloudWatch, CloudWatch Logs, Config, Cognito, IAM Identity Center, OpenSearch Service,
Comprehend Medical, Control Tower, Organizations, API Gateway, ELB, ECS, EKS and Neptune.

**C1 — features inherit.** "Unless specifically excluded, generally available features of each of
the HIPAA eligible services listed are also considered HIPAA eligible." Glue Data Quality is a
generally available feature of Glue, so it needs no separate entry.

**C2 — a nuance worth knowing.** Entity Resolution's own compliance validation page names PCI DSS
and SOC 1/2/3 and never mentions HIPAA. Its eligibility rests on the eligible services reference;
cite that.

**C3 — the Preview problem, the most important caveat in this set.** C1 extends eligibility to
*generally available* features. HealthLake resource matching is "available as a preview capability
and is subject to change", and the Data Transformation Agent is also Preview. A Preview feature is
not generally available, so the cited pages do not establish that PHI may be processed through those
two features under the BAA. That is an inference from the quoted sentences, not an AWS statement,
and it is a question for an AWS account team. Until it is answered, run production on AWS Entity
Resolution and pilot HealthLake matching on synthetic or de-identified data.

Two companion questions belong on the same list, and the cited pages answer neither: does AWS use
customer input to Entity Resolution's preset ML model, and how long are the hashed attributes
`GetMatchId` produces retained? Asking is the right posture; inventing answers is not.

**C4 — Audit Manager is closed.** Its documentation now carries the banner "AWS Audit Manager is no
longer open to new customers. Existing customers can continue to use the service as normal." The
dated change behind it — "from April 30th 2026 customers will no longer be able to set up the
service in new accounts" — has passed, so a new landing zone cannot adopt it. Its HIPAA Security
Rule: Feb 2003 framework has 24 automated, 61 manual controls and 5 control sets, with its own
disclaimer that these "aren't intended to verify if your systems are compliant with the HIPAA
standard".

**C5 — Clean Rooms is listed but is not a healthcare service.** Its overview never mentions PHI,
HIPAA or healthcare; it is relevant only for cross-organisation analysis with a partner.

**C6 — naming.** Amazon DataZone is the name on the page; rebranding under the SageMaker Catalog
name was not verified here.

**C7 — PrivateLink.** VPC is listed; AWS PrivateLink is not, so it is covered by C1 as a generally
available feature of VPC. HealthLake's documentation independently names AWS PrivateLink as a
related service for connectivity "without exposing data to the internet".

**C8 — two bracketed caveats to read in full.** SageMaker AI is "[formerly Amazon Sagemaker,
excludes Studio Lab, Ground Truth Plus, Public Workforce and Vendor Workforce for all features]" —
the workforce exclusions rule out a managed human-review workforce for steward tasks. Amazon RDS is
"[SQL Server, MySQL, Oracle, PostgreSQL, Db2 and MariaDB engines only]"; Aurora is a separate entry
with no bracket, and Aurora is what this pattern uses.

## Shared responsibility, concretely

HealthLake "stores encrypted customer content and operates according to the AWS Shared
Responsibility Model". In practice:

The generic split — facilities and patching to AWS, IAM and configuration to you — is assumed. The
HIPAA-specific half is what matters:

| AWS is responsible for | You are responsible for |
| --- | --- |
| Making a service HIPAA eligible | Executing the BAA before PHI lands |
| Encryption primitives | Which services hold PHI, and key policy |
| Audit log generation | De-identification, minimum necessary, retention |

AWS cannot make you compliant; it can only make compliance constructible.

## Encryption

Encryption in transit is largely settled by the services. HealthLake: "Connections to HealthLake
containing PHI and personally identifiable information (PII) must be encrypted. By default, all
connections to HealthLake use HTTPS over TLS." Comprehend Medical says the same and adds: "Amazon
Comprehend Medical does not persistently store customer content. Therefore, you do not need to
configure encryption at-rest within the service."

At rest, use customer managed KMS keys, one per zone, and treat the key policy as a second
independent access control: a principal needs both an IAM grant and a key grant, so a mistaken
bucket policy alone does not expose PHI. Keys are $1 per month each, so separation is cheap.

Entity Resolution supports this: it "can operate on encrypted datasets", "equips you with an
encryption key for every data input into the service", and if a KMS key ARN is not provided "system
will use an AWS Entity Resolution managed KMS key" — so supply your own. It can also hash output
with "Secure Hash Algorithm 256-bit (SHA256)", useful where a consumer needs linkage without
plaintext identifiers.

## Least privilege and access

Lake Formation is the lever: it "provides its own permissions model that augments the IAM
permissions model", with permissions "enforced using granular controls at the column, row, and
cell-levels" across Athena, Redshift Spectrum, EMR and Glue. Grant analysts a column-filtered view
omitting name, address, dates of birth and source identifiers, and use LF-Tags to manage those
grants at scale rather than per table.

Be precise about what that view produces, because the terminology carries legal weight. A view
retaining `master_id` is **pseudonymised PHI, not de-identified data**: `master_id` re-identifies
every row once joined to the crosswalk, and it is by design the enterprise key used for every other
purpose. Treat it as PHI — inside the BAA, inside the Data OU's controls, with the crosswalk
unreachable from the analytics account. A genuinely de-identified extract is a separate product,
needing the linking code removed or replaced by a per-extract value whose key is not disclosed, plus
suppression, generalisation and date shifting.

Humans authenticate through IAM Identity Center federated to the corporate identity provider; no
long-lived IAM users. Cognito serves patient- or partner-facing applications. Service roles are
scoped to specific bucket prefixes and KMS keys.

## Audit

| Layer | Mechanism |
| --- | --- |
| API activity | CloudTrail organisation trail to the log archive account |
| PHI object access | CloudTrail data events on the raw and curated buckets |
| Analytics access | Lake Formation "provides comprehensive audit logs with CloudTrail" |
| Configuration | AWS Config with the HIPAA Security conformance pack |
| Findings | Security Hub CSPM across accounts |
| Log integrity | Object Lock on the archive; CloudTrail log file validation |
| Master changes | Your append-only history table in Aurora |

The Config conformance pack is AWS's own recommended route, and carries a disclaimer worth quoting
rather than paraphrasing: "Conformance Packs, as sample templates, are not designed to fully ensure
compliance with a specific governance or compliance standard. You are responsible for making your
own assessment of whether your use of the Services meets applicable legal and regulatory
requirements." Its rules include `s3-bucket-server-side-encryption-enabled`, `cloudtrail-enabled`,
`rds-storage-encrypted` and `vpc-flow-logs-enabled`.

The last row is yours: no AWS service records which attribute of a golden record changed, why, and
on whose authority.

Two sinks this table omits accumulate PHI nobody governs. **CloudWatch Logs**: Glue and Lambda logs,
and any error path logging a record, carry PHI — suppress record-level logging in production,
encrypt log groups with a CMK, set retention, scan any log export bucket. **The Athena query-results
bucket**: every query writes its results to an output location, so it fills with analyst-made PHI
extracts outside the curated zone's governance; give it its own CMK, a lifecycle expiry, Lake
Formation scoping and Macie coverage. Step Functions execution history is a third — see document 06.

## Macie, and what it does not cover

Macie "uses a combination of criteria and techniques, including machine learning and pattern
matching, to detect sensitive data in Amazon Simple Storage Service (Amazon S3) objects". Seven
types sit in its PHI category, each needing a nearby keyword:

| Type | Identifier | Region |
| --- | --- | --- |
| DEA Registration Number | `US_DRUG_ENFORCEMENT_AGENCY_NUMBER` | US |
| Health Insurance Claim Number | `USA_HEALTH_INSURANCE_CLAIM_NUMBER` | US |
| Health insurance or medical ID | `UK_NHS_NUMBER`, `CANADA_HEALTH_NUMBER`, four more | Several |
| HCPCS code | `USA_HEALTHCARE_PROCEDURE_CODE` | US |
| National Drug Code | `USA_NATIONAL_DRUG_CODE` | US |
| National Provider Identifier | `USA_NATIONAL_PROVIDER_IDENTIFIER` | US |
| Unique device identifier | `MEDICAL_DEVICE_UDI` | US |

PII identifiers matter as much here. `NAME` is the only *personal-information* identifier needing no
nearby keyword — its "Full name" row reads "Keyword required: No". `DATE_OF_BIRTH` and
`USA_SOCIAL_SECURITY_NUMBER` require one; `ADDRESS` and `PHONE_NUMBER` are "Varies". Several
credential and IBAN identifiers also need none, so "only NAME needs no keyword" holds for the
personal-information rows, not the whole table.

The scope limit is the honest part. Macie is a control over S3, not a scanner for Aurora, DynamoDB,
Redshift or HealthLake. Its best use is detective, on the landing zone and any extract bucket — "did
PHI arrive somewhere it should not have" — not inventorying the master.

## De-identification

A de-identified copy is the right answer for every non-production environment, and it is a customer
obligation. The nearest managed primitive is Comprehend Medical's `DetectPHI` (entity types in
document 03).

Its own page sets the boundary, and this is the sentence to remember: "Amazon Comprehend Medical
detects entities associated with these identifiers but these entities don't map 1:1 to the list
specified by the Safe Harbor method." Volunteer the counterweight from the same paragraph rather
than waiting to be given it — AWS also writes that it "does cover all the relevant identifiers" for
unstructured text, so the limit is the mapping to Safe Harbor, not coverage. It recommends "human
review or other methods to confirm the accuracy of detected PHI", and it is English-only.

So: a strong aid for free text, not a de-identification control and not a Safe Harbor
implementation. Structured de-identification of the master's columns is custom work. The statutory
identifier list is not reproduced here; confirm it against HHS directly.

## Break-glass

No AWS service here provides an emergency access workflow, so build one and keep it boring. A
dedicated role, assumable only after a ticketed, time-boxed approval, never by a standing principal.
Every assumption emits an EventBridge event and a Security Hub finding. CloudTrail is the record,
written to an account the role cannot reach, and a review follows every use. The same
discipline applies to the steward console's override path: a steward who can merge any two patients
is a privileged user in the HIPAA sense, with or without an AWS console.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 131 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/aws/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->