The Subsidiary That Wasn't in the SOW

Out of scope as written - do not test it.

Reasoning chain:

1. Scope is defined by authorization, not by what the target looks like. The client's logo and certificate prove the client operates an application there; they do not prove the client controls the IP address. Address registration points to the MSP.
2. The SOW already decided the grey area. The exclusion for third-party/hosted infrastructure is broad and unambiguous. A tester cannot resolve ambiguity in their own favour; ambiguity is resolved by the party who can grant permission.
3. Two authorizations may be needed. Even if the client owns the application, testing an MSP-hosted platform can affect the MSP's other tenants and may breach the MSP's own contracts.

Concrete steps:

• Stop enumeration against that address; log what you already observed (cert SAN, banner, IP registration) as passive evidence only.
• Send a written request to the SOW signatory (or a delegate with documented authority) asking for either a scope amendment naming the IP and the MSP, or written confirmation from the MSP.
• Record the pause in the daily log with timestamps. If the client says "just try it," that is a verbal instruction from an unverified authority - escalate in writing and wait.
• If permission arrives, re-confirm it covers the specific host and testing window, then proceed under existing rate limits and no-DoS rules.

Do not open, copy, or download the files. Stop at the listing you already have.

The judgement point is that knowledge of an exposed share is a finding; retrieval of the contents converts a scoped test into an unauthorized access event with breach-notification consequences for a legal entity that never authorised you.

Immediate actions:

1. Cease interaction with the host; do not authenticate, do not run enumeration scripts against the share.
2. Preserve only the minimum: the hostname/IP, the timestamp, and the fact that a share was visible with payroll-named files. Do not store file contents or payroll data.
3. Notify in writing the SOW signatory and the client's security/legal contact the same day, describing the exposure - not the contents.
4. Recommend the client treat it as a potential data-exposure incident for the subsidiary, on the subsidiary's own IR track. The subsidiary's authorisation is a separate matter from the parent's.
5. Offer the fix as a scope change, not a favour: a change order naming the subsidiary's range and adding the subsidiary as a party.

Report language: list it under "Out-of-scope observations" with the recommendation and the fact that testing was declined pending authorisation. That framing protects both parties and gives the client something actionable.

Decline the screenshot, accept nothing verbally, and document the exchange.

The IT manager signed the SOW, so he may be able to authorise narrow additions - but a blanket "anything you find" is not a lawful or workable scope. It is unbounded, granted under time pressure, and given by a party whose authority over the subsidiary and the MSP is unknown.

Response structure:

• Explain the constraint in business terms: "Acts outside the agreed scope are not covered by the engagement's liability and indemnity terms, so the exposure lands on the company, not on us."
• Offer a fast substitute that satisfies his real need: a same-day summary of in-scope findings plus a one-paragraph out-of-scope observation list, with no payloads, no PII, and no screenshots of data.
• Give him a concrete path: a signed scope-addendum template he can forward; state that you can start within an hour of receiving it.

Documentation:

• A dated note of the request, your response, and the fact that you did not act on it.
• Any screenshot you do produce should be of configuration (share name, banner, TLS certificate), never of records.
• Mention in the report that instructions were received from a non-signatory channel and were not actioned, so the audit trail is complete.