The Patient ID That Belongs to Someone Else
Northwind Health engages you to test a bespoke patient-portal web application and the API behind it. The signed RoE lists two in-scope hosts (portal.northwind-health.example, api.northwind-health.example), permits authenticated testing with two provided accounts created for synthetic patients, and forbids denial-of-service, social engineering, and any testing outside 08:00-18:00 UTC. The portal calls a FHIR API operated by a third-party SaaS vendor, CareBridge, which hosts Northwind and eleven other tenants behind a shared gateway. At 14:20 you notice the portal passes a numeric patientId to api.northwind-health.example, which proxies to CareBridge. Incrementing it by one returns another patient's allergy list. Your assigned client contact is the IT director; the RoE was signed by the CISO.
1. Is the patientId enumeration in scope, and what do you do before sending another request?
Read the worked answer
The authorization question is about which asset you touch, not which data comes back. The request goes to api.northwind-health.example, which is named in the RoE, so sending it is authorized. What is not authorized is harvesting records belonging to patients who are not Northwind's, and the RoE scopes your accounts to two synthetic patients. A boundary you were not asked to test being crossed by a response is a finding, not a licence.
Before any further request: stop incrementing. One request that returned another patient's allergy list, captured with request, response, timestamp and the account used, is sufficient proof of an access-control failure. A second increment adds no evidential value and doubles the personal data you have mishandled. Record the response as field names and a hash rather than the clinical content itself. Then escalate to the engagement manager and the CISO's named security contact the same day, in writing. If you genuinely need a second data point to write an accurate report, ask the client to create a third synthetic patient and demonstrate the off-by-one between two records they own.
2. Your second increment returns records belonging to a patient at a different CareBridge tenant. What now?
Read the worked answer
You are now holding another organisation's data, and the clock matters more than the analysis. Cease testing the parameter, do not open, copy or index the other tenant's records, preserve only what you already received, and notify immediately rather than at report delivery.
The notification chain is Northwind to CareBridge. Northwind is controller for its own patients but has no authority over CareBridge's other tenants, and you cannot contract your way into authorizing a test of them. Flag it as a suspected personal-data breach: under most regimes the controller has 72 hours from awareness, and awareness may start at your discovery, not at report delivery. Keep the affected record count exact and minimal. Note also that the shared gateway means the defect probably affects every tenant, which is CareBridge's remediation to own, not yours to enumerate.
In the report, describe the flaw and its blast radius without reproducing third-party data. Get engagement-lead sign-off on the wording before it leaves your hands.
3. The IT director asks you to 'just quickly' check the CareBridge admin console, which is outside the testing window and not in the RoE. How do you respond?
Read the worked answer
Decline, in writing, and explain why plainly. The console is a CareBridge asset operated by a different legal entity, is neither in the RoE nor inside the agreed window, and 'quickly' describes effort, not authorization. A verbal request from an IT director is not a valid scope change: your contract names who may amend scope, and it will be the CISO who signed the original.
Offer a concrete path instead: a written scope amendment signed by Northwind, plus written authorization from CareBridge as asset owner, plus a new testing window, and a note that CareBridge's own terms may forbid testing its production tenancy at all. If pressed, point out that unauthorized access to a third party's system is a criminal matter regardless of who asked for it.
Log the request, your refusal, and the date, and repeat it in the daily status email so it sits on the record rather than in a chat thread. Silence or a shrug will later be read as agreement.