Incident Response Checklist for a Misconfigured S3 Bucket in a Sleep Study Scoring Service

A misconfigured Amazon S3 bucket can expose sleep study files, scoring outputs, and identifying records. Treat the event as both a security incident and a potential privacy incident: contain access promptly, preserve available evidence, identify affected records, and have privacy and legal teams assess notification duties.

How should responders contain access to the exposed S3 bucket?

1. Coordinate and record the response. Assign an incident lead, involve cloud security, the service owner, privacy, and legal teams, and note the discovery time, responders, and actions taken.
2. Capture the current configuration, then restrict access. If doing so will not delay urgent containment, save the current bucket policy, S3 access control list (ACL), Block Public Access settings, access-point policies, and relevant account settings. Then enable all four Amazon S3 Block Public Access settings at the bucket level and, where appropriate, at the account level.
3. Remove the public grant. Review and correct the bucket policy and ACL rather than relying on Block Public Access alone. AWS notes that these settings block public access but do not remove existing policies or ACLs; an underlying public grant could become effective again if the block is later disabled. Check identity-based policies and access points as well. See AWS guidance on blocking public access to Amazon S3 storage.
4. Preserve necessary service access. Confirm that the scoring service’s authorized IAM role can still read and write only the required prefixes and objects. Test the service after restrictions take effect, and use controlled temporary access for responders rather than restoring broad permissions.

Amazon S3 applies the most restrictive applicable Block Public Access settings across organization, account, bucket, and access-point levels. Check the effective configuration and verify that anonymous requests are denied after containment. AWS describes the four settings and their interaction in its Block Public Access documentation.

How can teams identify affected sleep study files and records?

Establish the exposure window: when the public permission first became effective, when it was removed, and whether other public-access routes existed. Review configuration history, deployment records, and relevant AWS CloudTrail management events to determine when bucket policies, ACLs, or Block Public Access settings changed.

Build an inventory of objects that could have been exposed. Use object listings, available S3 Inventory reports, version information, application databases, and scoring-service records to map object keys to studies and people. Look for identifiers in filenames, metadata, manifests, and associated records; sleep waveforms or scoring results may be identifiable when linked to a patient or study ID. Record the object key, version, relevant timestamps, data categories, and the basis for associating it with an individual.

Determine what access can be established from available logs. An object-level access audit may use AWS CloudTrail data events to examine object API calls such as GetObject, along with timestamps and available requester details. But CloudTrail does not log S3 data events by default, and enabling it now will not recreate past events. S3 server access logging may provide another source if it was enabled and delivering logs during the exposure period. AWS explains these options in its documentation for CloudTrail S3 data events and Amazon S3 logging.

Correlate AWS records with application, identity-provider, API gateway, and network logs where available. Separate confirmed accesses from suspicious or unattributed requests, and distinguish evidence of a successful read from a denied request. If relevant logs were not enabled or retained, document that limitation; the absence of logs is not proof that no one accessed the files.

What evidence should be preserved during the investigation?

Preserve evidence before making changes when feasible, but do not delay urgent containment to complete collection. Capture the original and corrected bucket policy, ACL, Block Public Access settings, access-point configuration, object listing, relevant IAM permissions, and the timeline of each response action.

• Export available CloudTrail management and data events, S3 server access logs, AWS Config history, and relevant application and identity logs.
• Preserve object keys, versions, metadata, and timestamps needed to identify exposed records. Avoid deleting or overwriting potentially relevant objects during the investigation.
• Store evidence in a separate, access-restricted destination that is not exposed by the incident. Limit access to authorized investigators and document collection, transfer, and analysis.
• Record which sources were unavailable, when logging began or ended, and any retention gaps that affect conclusions.

CloudTrail S3 data events can record object-level API activity, but AWS states that trails do not log data events by default and that additional charges apply. S3 server access logging is another possible source when configured. Preserve existing records and configuration history; do not assume that enabling either logging option after discovery will provide a complete historical record. See AWS guidance on CloudTrail data events and enabling S3 server access logging.

How should exposed data and access credentials be secured?

Keep the bucket private and remove any unnecessary public or overly broad permissions from its bucket policy, S3 access control list, access points, and related IAM policies. Prefer policy-based, least-privilege access; AWS recommends keeping ACLs disabled unless object-level ACL control is necessary. Confirm that only the scoring service’s approved roles and authorized personnel can access the required objects.

Assess whether credentials or tokens may also have been exposed. If so, disable or revoke affected keys, rotate application secrets and credentials stored in the bucket, and review for unauthorized creation or use of identities and access grants. Revoke or replace affected session tokens or signing material where applicable. Do not assume that closing public access also secures leaked credentials.

Review encryption and key access for the affected files. Encryption at rest does not by itself show whether information was protected from someone who could access the objects through the service or its keys. Determine whether the information was encrypted in a way that rendered it unusable, unreadable, or indecipherable to unauthorized people, and document who could access the relevant keys.

How can teams assess notification and reporting obligations?

First determine whether the files contain protected health information (PHI), whether the information was unsecured under the applicable HIPAA guidance, and whether an impermissible access or disclosure occurred. A publicly accessible bucket can create a serious exposure, but the configuration alone does not settle whether notification is required. Involve the covered entity’s privacy officer and legal counsel promptly, and review business associate agreements, contracts, and applicable state requirements.

Under HHS’s HIPAA Breach Notification Rule guidance, an impermissible use or disclosure of PHI is generally presumed to be a breach unless an exception applies or the covered entity or business associate demonstrates a low probability that the PHI was compromised through a documented risk assessment. That assessment must consider the nature and extent of the information, who received or used it, whether it was actually acquired or viewed, and how the risk was mitigated. See HHS guidance on the Breach Notification Rule.

If notification is required, HIPAA generally requires covered entities to notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery. Breaches affecting 500 or more individuals also require notice to the HHS Secretary without unreasonable delay and within that limit; breaches affecting fewer than 500 individuals are reported to the Secretary within 60 days after the end of the calendar year in which they were discovered. A business associate must notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery, subject to the applicable rule and agreement. See HHS’s breach reporting instructions and its information on individual and business associate notification. These are outside deadlines, not a reason to postpone required action.

What recovery steps verify the scoring service is secure?

Before returning the service to normal operation, verify that the bucket is no longer publicly accessible and that public grants have been removed from the relevant policies and ACLs. Test access from an unauthenticated context, then confirm that the approved scoring-service role can perform only its required actions and that unauthorized roles are denied.

Review application and deployment configurations for changes that could recreate public access, including infrastructure-as-code templates, automated deployments, and service roles. Add monitoring for bucket-policy, ACL, and Block Public Access changes; configure and protect CloudTrail data events or other suitable object-level logging for future investigations. AWS notes that CloudTrail data events must be selected for logging and may incur additional charges.

Run an end-to-end scoring test using a controlled study record, check that outputs are stored in the intended private location, and confirm that the service’s dependencies still function without public access. Document findings, affected records, evidence gaps, remediation, and any notification decisions. In short, recovery is complete only when access follows the least-privilege access principle, logging is adequate for future review, and privacy teams have a documented assessment of the exposed sleep study data.

FAQs.

How do responders quickly restrict public access to an S3 bucket?

Enable all four Amazon S3 Block Public Access settings on the bucket, and consider applying them at the account level as well. Then remove public grants from the bucket policy and any enabled S3 access control list, and check access points and relevant identity-based policies. Verify that anonymous access is denied while the scoring service retains only the permissions it needs.

What evidence should be retained before changing the bucket configuration?

When feasible without delaying urgent containment, preserve the bucket policy, ACL, Block Public Access and access-point settings, object inventory and versions, and relevant AWS Config and CloudTrail records. Retain any S3 server access logs and related application or identity logs. Record timestamps, collection actions, access to evidence, and any missing logs or retention gaps.

How can teams determine whether sleep study files were accessed?

Review available CloudTrail S3 data events and S3 server access logs for object requests during the exposure window, then correlate them with application and identity logs and map object keys to study records. CloudTrail data events are not enabled by default, and logs enabled after discovery do not establish what happened earlier. Document what the available evidence confirms and what it cannot determine.

When may a misconfigured bucket trigger breach notification obligations?

If the bucket exposed unsecured PHI through an impermissible use or disclosure, HIPAA’s Breach Notification Rule may apply. The covered entity or business associate must assess the applicable exceptions and, where relevant, document whether the required risk assessment demonstrates a low probability that the PHI was compromised. Involve the privacy officer and legal counsel to evaluate the facts, applicable deadlines, contracts, and other laws.