The SaaS Link You Were Not Authorized to Follow
Meridian Health engaged your firm under a statement of work that authorizes testing of the 10.20.0.0/24 range and seven named external FQDNs, between 09:00 and 18:00 local time, with no denial-of-service techniques, no social engineering, and an explicit exclusion for 'systems operated by third parties.' On day two, while authenticated as a low-privilege test account on claims.meridian.example, you notice the login page pulls JavaScript from portal.claimsprovider.example, a SaaS clearinghouse, and the bundle calls an API in 198.51.100.0/24. Later, the IT operations manager messages you: 'While you're in there, can you look at why the billing SQL box at 10.20.5.9 keeps crashing? Just run a quick scan.' Separately, a misconfigured endpoint returned a downloadable CSV containing 4,000 member records (names, dates of birth, policy numbers) before you closed the tab.
1. Do you test portal.claimsprovider.example or the 198.51.100.0/24 API? Justify the decision and state exactly what you record.
Read the worked answer
No - and the reasoning stacks three independent grounds, any one of which is sufficient.
- Scope text. The SoW names 10.20.0.0/24 and seven FQDNs. Neither the SaaS host nor the API range is on either list. Scope is defined by what is written, not by what is reachable from an in-scope page.
- Third-party exclusion. The clearinghouse is a separate legal entity that has signed nothing. Meridian cannot authorize testing of a system it does not own or control, so the client's permission does not transfer. Testing the vendor would be an unauthorized act regardless of Meridian's blessing.
- Derivation of authority. A tester's authorization is entirely derivative of the asset owner's consent. That consent stops at the tenant boundary, and a link in HTML the client served does not extend it.
Recording: timestamp, the observed URL and resource, and a screenshot of the client's page only - no traffic to the vendor host, no DNS resolution sweep of the API range. Report it as an exposure observation, not a vulnerability: 'client portal depends on third-party JavaScript and an external API; confirm the vendor's security attestation and data-processing agreement, and consider a separately authorized test.' Offer to have the client broker an introduction so the vendor can scope its own engagement. Log the decision in the daily activity log so there is contemporaneous evidence of restraint if the question is raised later.
2. How do you handle the operations manager's request to scan 10.20.5.9, and why is the answer not simply 'yes, it is in our /24'?
Read the worked answer
The address is in the authorized range, but authorization, target suitability, and change control are three separate questions, and this request fails the second and third.
Authority. An operations manager is not necessarily the signatory named in the SoW. A scope change needs a written change order or an email from the authorized signatory, carrying the same clauses (window, no-DoS, data handling, indemnity). A chat message is evidence that someone asked, not that the client agreed to vary the contract.
Suitability. The host 'keeps crashing.' Running an active scan against an already unstable production database is a direct availability risk and collides with the no-DoS clause. If it crashes during your scan, the outage is attributed to you regardless of root cause, and you will spend the rest of the engagement defending the timeline.
Counter-proposal. Offer a read-only health check with plugins limited to non-intrusive checks, outside business hours, with the DBA present, under a signed change order. Point out that diagnosing a crash is troubleshooting, not a security assessment, and should be a separate work item.
Record the decline and the reason in the daily log, retain the message, and escalate to your engagement manager if the request is repeated informally. Verbal convenience is the most common way testers end up outside their authorization.
3. You have inadvertently downloaded a CSV of 4,000 member records. What are your immediate handling obligations, and how does this appear in the report?
Read the worked answer
Treat it as an incident you caused, not as a lucky find.
Contain. Stop interacting with the endpoint. Do not copy the file to personal devices, chat, shared drives, or the ticketing system. If a copy exists, move it to the encrypted engagement share with access restricted to the tester and engagement lead, record a hash, and note the chain of custody. Do not read further rows than necessary to characterize the finding.
Notify. Tell the client's named contact and privacy officer in writing within the incident window stated in the contract (commonly 1–24 hours). State what you accessed, when, how many records, and what you have retained. The client decides whether it is a notifiable event - that is their legal call, not yours.
Classify. Name + date of birth + policy number is identifiable health data: PHI under HIPAA in the US and personal data under GDPR for any EU residents in the set. Your firm is now a processor of that data, so the contract's data-processing clause governs retention and destruction; delete on the agreed schedule and confirm in writing.
Report. Write the finding as 'unauthenticated access to a member data export' with the record count, the request path, and remediation (authentication, object-level authorization, rate limiting, review of access logs for prior retrieval). Never paste member rows into the report, the tracker, or an email to illustrate the point.