Scope Creep at Hour Six: A Third-Party Range Inside the Corporate Network
You lead a six-person inspection team for a regional insurer. The signed authorization memo covers 10.20.0.0/16 and the portal at app.example-insure.test, with a 48-hour testing window. At hour six, discovery shows that 10.31.4.0/24 is reachable through a route advertised by a lab switch. That range hosts a claims-analytics cluster operated by a third-party analytics vendor under a separate managed-service contract. The contract requires ten business days' written notice before any security testing, and the engagement letter only says 'corporate network.' The steering committee meets at hour 24. One inspector already ran a credentialed configuration check against two hosts in 10.31.4.0/24 before the range was identified, and those results sit in the shared working folder. In-scope inventory is roughly 1,200 hosts. Forty-one hours remain and the deliverable date is fixed.
1. What is your immediate action regarding 10.31.4.0/24, and how do you handle the two hosts that were already tested?
Read the worked answer
Stop, contain, then decide.
- Halt active testing in 10.31.4.0/24 immediately and tell the team in writing. Do not wait for the hour-24 committee; every additional request deepens the exposure.
- Preserve rather than delete the two hosts' results. Deleting them looks like concealment and destroys the timeline you will need. Move the artifacts to a quarantined folder, record the exact commands, credentials used, start/stop times, source IPs, and what the check read versus changed.
- Assess impact of the credentialed check. A read-only config pull still authenticates, may create logon events, and may have used an account the vendor monitors. If the vendor contract has an access-notification clause, that clock may already be running.
- Escalate on two tracks: to the engagement lead/CISO for scope authority, and to legal for the contract question. A CISO memo cannot unilaterally waive a third party's notice right; 'corporate network' is ambiguous and does not resolve it.
- Ask for either written scope expansion from the vendor or a documented exclusion. Until one arrives, treat the range as out of scope.
- Keep the in-scope work moving so the 41 hours are not consumed by the dispute.
- Report it transparently as an out-of-scope asset discovered during discovery, with the containment actions and the two-host disclosure. Silent inclusion and silent omission are both reportable failures.
2. Design the sampling approach for the 1,200 in-scope hosts given 41 hours and six inspectors.
Read the worked answer
Full coverage is impossible; a credentialed config review plus manual validation realistically supports perhaps 150 to 250 hosts with six inspectors over 41 hours once travel, triage, and reporting are counted. So the design must be deliberate rather than exhaustive.
- Stratify first. Tier 0 assets (domain controllers, PKI, jump hosts, backup infrastructure), internet-facing systems, the cardholder-data zone, and crown-jewel databases get judgmental, near-complete coverage. These are where a single finding changes the risk conclusion.
- Random sample the remainder so the report can describe the population without cherry-picking only the worst hosts. State plainly that the sample is not statistically representative unless you actually sized it that way.
- Layer methods: automated authenticated scanning across everything reachable, manual verification on a subset to catch scan blind spots and false positives.
- Reserve roughly 15% of the window for exactly the kind of scope event that already occurred, plus incident triage and evidence packaging.
- Document inclusion and exclusion criteria in advance, with the asset owner's criticality ratings, so the selection cannot be second-guessed after the findings land.
- Avoid 'worst 20 only' selection. It produces dramatic findings but no defensible statement about the estate.
3. At hour 24 the steering committee says: 'It's our data, just include it.' How do you respond?
Read the worked answer
Acknowledge the business point, then separate two things that are being conflated: data ownership and testing authority.
- The insurer may own the claims data, but the cluster is operated by a vendor under a contract that imposes a notice obligation on the parties doing the testing. Ownership does not transfer the vendor's contractual rights, and the CISO's memo binds the insurer, not the vendor.
- Including the range without consent risks breach-of-contract claims, loss of the right to test in future engagements, possible disturbance of live claims processing, and in some jurisdictions an unauthorized-access argument. It also taints the report: findings from an unauthorized range are hard to defend in front of an audit committee or regulator.
- Offer concrete alternatives rather than a flat refusal:
- Request expedited written authorization from the vendor today, with a defined window and rules of engagement.
- Review configuration data the vendor has already provided to the insurer under the service agreement.
- Test only insurer-controlled ingress paths to the cluster, not the cluster itself.
- Record the decision, who made it, and any dissent in the engagement file. If overruled, escalate to legal in writing before acting; a documented objection protects the team and the programme.
- Keep the two already-touched hosts in the report either way.