Incident Response Checklist for Compromised AWS Keys at a Clinical Decision Support API Vendor

A compromised AWS key can expose more than cloud infrastructure: it may enable access to a clinical decision support API, connected data stores, or systems containing protected health information (PHI). Act quickly to contain the credential, preserve evidence, determine what it could access, and coordinate with affected customers.

Use this checklist alongside your incident response plan and business associate agreements (BAAs). AWS containment steps help secure your environment, but they do not replace a documented HIPAA breach assessment or legal guidance.

How should a vendor contain compromised AWS access keys?

Start by identifying the exposed access key ID, the associated IAM user or role, the AWS accounts and environments where it is used, and when it may have been exposed. Treat the secret access key as compromised even if you have not yet confirmed unauthorized activity.

• Deactivate the specific long-term access key promptly. This blocks new requests signed with that key. Coordinate with the service owner and have a safe replacement or workload identity ready to minimize disruption to the API.
• Do not confuse rotation with containment. Create and deploy a replacement only through a controlled process; a new key does not neutralize the exposed one. AWS describes updating keys by creating a replacement, updating applications, and then deactivating the old key in its access-key update guidance.
• Check whether the credential is temporary. If it belongs to an assumed role, revoke active role sessions or deny the affected session as appropriate. AWS notes that revoking role sessions can affect legitimate users, so coordinate the action with service owners using its temporary credential revocation guidance.
• Contain related identities and secrets. Review whether the same credential, secret, or deployment mechanism was reused elsewhere. Disable other confirmed compromised credentials and examine connected systems for unauthorized access or persistence.
• Preserve evidence. Record the key ID, identity, discovery time, deactivation time, affected accounts and regions, and actions taken. Keep investigation logs in a protected location.

For an AWS IAM user’s long-term key, deactivating the affected key is an immediate containment measure; rotating and redeploying credentials is a separate recovery task. For temporary credentials, use temporary security credential revocation controls appropriate to the credential type.

How can CloudTrail and AWS resources reveal unauthorized activity?

Use the AWS CloudTrail event history as an initial source for identifying management actions made with the exposed key. Search the relevant AWS accounts and regions for the key ID and review events before and after the suspected exposure. CloudTrail event history provides searchable management events from the past 90 days on a per-region basis, as described in the AWS CloudTrail event history documentation.

Inspect each event’s identity and request details. CloudTrail records may show fields such as userIdentity.accessKeyId, the principal or session, eventName, eventTime, sourceIPAddress, and the affected AWS region. Compare those details with expected vendor services, deployment activity, approved IP ranges, and change records. See AWS’s documentation on CloudTrail identity fields and event record contents.

Look for unexpected authentication, role assumptions, policy or identity changes, new access keys, unusual resource creation, changes to logging, and access to storage, databases, secrets, or encryption keys. Consider whether unauthorized changes could have affected API availability, clinical outputs, or the integrity of data used by the decision support service.

Do not treat the absence of an event in event history as proof that no data was accessed. Event history does not include data events, and CloudTrail trails do not log Amazon S3 object-level data events by default. Check whether the relevant data events were enabled during the incident, and review other available evidence, such as application and API logs, database audit logs, load balancer and network logs, GuardDuty findings, and identity-provider records. AWS explains these limitations in its guidance on CloudTrail event history and S3 object-level CloudTrail logging.

Preserve copies of relevant logs and correlate them into a timeline. Note gaps in retention, disabled logging, or incomplete data-event coverage so the investigation does not mistake missing telemetry for evidence of no access.

What steps are needed to remove unauthorized access and restore services?

After containing the key, investigate and remove unauthorized changes before returning the affected workload to normal operation. A compromised identity may have been used to create additional credentials, alter permissions, deploy resources, or change logging and network configurations.

1. Inventory affected resources. Review IAM users, roles, policies, trust relationships, access keys, and role sessions. Check relevant compute, storage, database, secrets, networking, and logging resources in every affected account and region.
2. Remove unauthorized access and persistence. Delete or disable credentials and resources confirmed to be malicious. Revert unauthorized policies, trust relationships, security group rules, and configuration changes. Confirm that logging has not been disabled or redirected.
3. Replace exposed secrets safely. Generate new credentials where needed, store them in an approved secrets-management system, and update applications and deployment pipelines. Do not put replacement secrets in source code, tickets, or chat.
4. Validate service integrity. Verify that the API, its dependencies, and clinical decision support outputs are operating as expected. Investigate whether unauthorized changes could have affected availability, data integrity, or results returned to customers.
5. Restore from a known-safe state if needed. Use validated configurations and backups, and monitor restored services for renewed suspicious activity before closing the incident.
6. Document the response. Keep a timeline of containment, eradication, recovery, evidence reviewed, unresolved uncertainties, and decisions about customer notification.

Balance containment with service continuity: a rushed change can interrupt clinical workflows, while an incomplete cleanup can leave unauthorized access in place. AWS describes containment, eradication, and recovery as incident response activities in its Security Pillar incident-response guidance.

How should a vendor assess potential exposure of protected health information?

An exposed AWS key is a security incident, but it does not by itself establish that PHI was accessed or that a reportable breach occurred. Determine what the credential could reach, whether it was used without authorization, and whether the relevant data was acquired, viewed, used, or disclosed.

Map the key’s effective permissions to the vendor’s systems and data. Identify the API and customer environments, databases, object stores, backups, logs, and other resources it could access. Establish whether those resources contained PHI, what types of information were involved, which individuals or customers may be affected, and whether the information was encrypted in a manner that meets applicable HIPAA guidance.

For an impermissible use or disclosure of PHI, HIPAA generally presumes a breach unless the covered entity or business associate demonstrates a low probability that the PHI was compromised through a risk assessment. HHS identifies four factors to consider: the nature and extent of the PHI, including re-identification risk; who used or received it without authorization; whether it was actually acquired or viewed; and how far the risk was mitigated. Review the HHS Breach Notification Rule guidance and its four-factor risk assessment explanation.

Document the evidence for each factor, including logging coverage and limitations. Coordinate the assessment with the covered entity and follow the BAA, incident response plan, and applicable law. A conclusion that the evidence is incomplete should be documented as uncertainty—not treated as proof that PHI was not affected.

What HIPAA breach notification deadlines apply to business associates?

If a breach of unsecured PHI occurs at or by a business associate, HIPAA requires the business associate to notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery. Discovery generally begins when the breach is known, or would have been known through reasonable diligence, to the business associate. The notice must include, to the extent possible, information identifying affected individuals and other available information the covered entity needs. See 45 CFR § 164.410 and the HHS Breach Notification Rule.

The 60-day limit is an outer deadline, not a reason to wait. A BAA may require earlier reporting or specify how the business associate must provide updates and supporting details. Check the relevant contract and notify the covered entity promptly under its terms.

Covered entities are generally responsible for notifying affected individuals and the HHS Secretary, and for providing media notice when required. A covered entity may delegate notification tasks to the business associate, so confirm responsibilities in the BAA rather than assuming the vendor must—or must not—send those notices directly.

For a breach affecting fewer than 500 individuals, the covered entity must still notify affected individuals without unreasonable delay and no later than 60 days after discovery. The covered entity may report the breach to HHS annually; that report is due no later than 60 days after the end of the calendar year in which the breach was discovered. This later HHS reporting schedule does not extend the business associate’s deadline to notify the covered entity. See HHS notification requirements and its breach reporting instructions.

How can AWS IAM controls reduce the risk of future key compromise?

Reduce reliance on long-lived IAM access keys, especially for workloads that can use roles and temporary credentials. AWS recommends temporary credentials for workloads and least-privilege access for any IAM users that still require access keys. See AWS guidance on access-key controls and when to use IAM roles.

• Apply an AWS IAM least privilege policy. Grant only the actions and resources each service needs. Separate production and nonproduction permissions, review trust policies, and remove unused grants.
• Prefer workload roles and short-lived credentials. Use an appropriate AWS identity mechanism so applications obtain temporary credentials rather than relying on embedded long-term keys.
• Protect secrets throughout their lifecycle. Store secrets in an approved secrets manager, restrict who and what can retrieve them, and prevent them from entering source repositories, build logs, container images, and support tickets.
• Make IAM access key rotation controlled and auditable. Maintain an inventory of any remaining long-lived keys, their owners, purpose, and last use. Rotate keys under a documented process and remove keys that are no longer needed.
• Improve detection and evidence retention. Alert on unusual credential use and sensitive IAM changes. Configure multi-region trails and the data events needed to investigate access to sensitive resources, and retain logs in a protected location.
• Practice incident response. Test how your team identifies and deactivates a key, revokes temporary sessions, restores service, assesses PHI exposure, and notifies covered entities under the BAA.

These controls reduce the chance that a single exposed credential can cause broad or persistent damage. Keep the response sequence clear: contain the key, investigate the activity, assess possible PHI exposure, notify covered entities under applicable requirements, and harden the IAM and logging controls that failed.

FAQs

Should a compromised AWS access key be deactivated immediately?

Yes. Deactivate a confirmed compromised long-term access key promptly to block new requests signed with it, while coordinating a replacement or alternate workload identity to limit service disruption. If the exposed credentials are temporary role credentials, use the appropriate session revocation or permission-denial control.

How should a vendor investigate CloudTrail activity linked to an exposed key?

Search CloudTrail event history in each relevant account and region for the key ID and review the identity, action, timestamp, source IP address, and affected resources. Correlate findings with application, API, database, storage, and network logs. Remember that event history covers only recent management events and does not show data events; check whether the necessary data-event logging was enabled and document any evidence gaps.

When must a business associate notify a covered entity about a breach?

The business associate must notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery of a breach of unsecured PHI. The BAA may require earlier notice, so follow its specific reporting terms and notify the covered entity promptly.

What are the HIPAA notification deadlines for breaches affecting fewer than 500 people?

The business associate’s deadline to notify the covered entity remains without unreasonable delay and no later than 60 calendar days after discovery. The covered entity’s individual notices are generally due without unreasonable delay and no later than 60 days after discovery. The covered entity may report a breach affecting fewer than 500 individuals to HHS annually, no later than 60 days after the end of the calendar year in which it was discovered.