The Third-Party Payroll File
Two weeks after completing an external test for a client, you review your notes and realise that during testing of a shared hosting IP you accessed an S3 bucket that was world-listable. You downloaded a single file named payroll_2024.csv to confirm the exposure. The file contained payroll records for a different company that shares the hosting provider. Your rules of engagement say to stop testing and notify the client immediately if third-party data is encountered. The client's manager asks you to delete the finding from the report because 'it's not our bucket and it will complicate the audit.' The report is due tomorrow. You still have the file on your testing laptop, and the bucket URL was outside the client's listed domains but the IP was in scope.
1. What are your immediate actions regarding the file and the notification?
Read the worked answer
Stop all testing related to the bucket. Do not download anything else, and do not browse further objects.
Preserve minimal evidence: record the bucket URL, the object name, the download time, file size, and a SHA-256 hash. Do not open the file again or copy it into the report. Isolate the file on the testing laptop in an encrypted container, or delete it securely if your legal team instructs that third-party PII must not be retained; either way, document the action, time, and reason. Notify your engagement manager and the client sponsor immediately, in writing, that third-party payroll data was encountered. Advise the client to contact the hosting provider and its legal/privacy team, because breach-notification obligations may apply. Do not contact the third party yourself unless the client or your legal team directs it. Keep the notification factual and avoid speculation about the third party's identity.
2. The client manager asks you to remove the finding. How do you respond?
Read the worked answer
Refuse to remove the finding. Explain that the report must be accurate and that omitting a known exposure of third-party personal data would misrepresent the engagement and could breach your professional and contractual obligations. The bucket was discovered through an in-scope IP, so it is relevant to the client's shared-hosting risk even if the bucket belongs to another tenant.
Offer a compromise that preserves accuracy: present the finding with redacted evidence, no PII, and a clear note that the bucket is outside the client's listed domains but on an in-scope shared IP. Record the client's request and your response in the report's management-response section or an appendix. Escalate to your engagement manager and legal contact. If the client still insists, do not alter the finding; let the escalation process decide how the engagement is closed.
3. Write the finding summary in a way that is useful to the client but contains no PII.
Read the worked answer
Finding title: World-listable S3 bucket on shared hosting IP exposed third-party payroll data.
Summary: During testing of an in-scope shared hosting IP, a world-listable S3 bucket was identified. A single file was downloaded to confirm the exposure and was found to contain payroll records belonging to another tenant of the hosting provider. No customer data from the client was accessed. The file was not retained in the report and was handled according to the engagement's data-handling procedure.
Impact: Unauthenticated parties could list and download payroll records, creating privacy, regulatory, and fraud risk for the third party and reputational risk for the hosting provider. The client should notify the hosting provider and review whether its own data is stored in similarly configured buckets.
Evidence: bucket URL, object name, access timestamp, file hash, and a screenshot showing the listing with object names redacted. Recommendation: restrict bucket policies, enable block-public-access, review shared-hosting isolation, and confirm notification obligations with legal counsel. Do not include employee names, salaries, bank details, or the third party's identity in the report body.