To prepare Amazon Quick for workflows involving protected health information (PHI), settle the account agreement, identity model, encryption-key choice and access controls before PHI enters the system. AWS describes Amazon Quick as HIPAA-eligible, but eligibility alone does not make a customer’s environment compliant: the customer remains responsible for its configuration, governance and safeguards.
What HIPAA eligibility covers
AWS says Amazon Quick is HIPAA-eligible across its web, desktop and mobile clients; its deployment guidance focuses on the web version. The Business Associate Agreement (BAA) is accepted through AWS Artifact for a specific AWS account. AWS says that agreement does not extend to other accounts or ineligible services, and it does not take the place of the customer’s own controls.
Start by identifying the account and services in scope, then accept the BAA for that account. The deployment still needs the customer’s safeguards and governance in addition to eligible service use.
Decide key and identity settings before setup
AWS says the account’s Amazon Quick data key is fixed when Quick data is first created, so choose it before that happens. Encryption at rest is enabled by default with AWS-owned or AWS-managed keys. A customer-managed key is optional, requires an Enterprise subscription, and must be selected before the first Quick data is created if it is to be the account’s key. AWS says deleting the key can leave unsubscribe and resubscribe as the only recovery, permanently removing Amazon Quick data.
Choose the identity model before provisioning users and permissions. AWS lists IAM Identity Center, Active Directory, IAM federation and Quick local users. If the identity provider changes later, AWS says permissions and space memberships must be reprovisioned. Inactive-user detection is available with IAM Identity Center or Active Directory.
| Decision | When to set it | Practical consequence |
| Account data key | Before Amazon Quick data is first created | AWS says the key cannot later be changed. Customer-managed keys are optional and require an Enterprise subscription. |
| Identity model | Before provisioning users and permissions | A later identity-provider change requires reprovisioning permissions and space memberships. |
| Document ACL awareness | When creating a supported knowledge base | AWS says it cannot be added afterward. Incorrect identity-to-ACL mappings can expose documents without an error or alert. |
Set access controls for each data path
For unstructured documents, create a supported knowledge base with document-level access-control-list (ACL) awareness enabled. Check that identity-to-ACL mappings match the intended document permissions before ingesting sensitive files. AWS gives a 24-hour default knowledge-base refresh cycle and recommends shortening it when access changes need to propagate faster.
Structured data uses a different set of controls. AWS’s fictional example separates S3 documents, retrieved through an ACL-aware knowledge base, from claims data that is curated and de-identified upstream. In that example, Lake Formation governs data-lake permissions, while an Athena-backed Quick Sight dataset applies row- and column-level controls. This is an illustrative architecture, not a customer deployment.
Configure and check audit records
Set up the audit streams before onboarding PHI-related work. AWS distinguishes CloudTrail, which records supported API operations and selected non-API events, from Amazon CloudWatch vended logs for Amazon Quick activity. CloudTrail does not capture chat message bodies or response content, according to AWS.
AWS names five CloudWatch log types: CHAT_LOGS, FEEDBACK_LOGS, AGENT_HOURS_LOGS, INDEX_USAGE_LOGS and KB_FILE_SYNC_LOGS. Chat and feedback records can contain PHI, so include their handling in the organization’s access and governance controls.
AWS’s deployment guidance recommends beginning with workflows that do not involve PHI, then checking governance, ACL behavior and logging before expanding use. AWS also describes Quick’s guardrails as probabilistic, so they should be supplemented with deterministic controls such as IAM policies, ACLs and network boundaries. AWS characterizes the service as single-Region, without cross-Region failover; a separate deployment and supporting data in another Region are presented as a possible recovery pattern.
Apply the six-year rule to the records it covers
The six-year period in 45 CFR §164.316 applies to documentation required by §164.316(b)(1): written policies and procedures, plus written records of actions, activities or assessments that the Security Rule requires to be documented. The period runs from the documentation’s creation or from the date it was last in effect, whichever is later. Read 45 CFR §164.316.
| Retention basis | What it covers | Period and start point |
| 45 CFR §164.316(b)(2)(i) | Documentation required by §164.316(b)(1) | Six years from creation or from the date it was last in effect, whichever is later |
| AWS implementation recommendation | Logs in the Amazon Quick deployment guidance | AWS recommends retaining logs for at least six years |
The regulation’s specified-documentation rule is not a blanket six-year requirement for every raw Amazon Quick log. AWS’s separate log-retention recommendation is an implementation practice, not the scope stated in §164.316(b)(2)(i).
