Scoping a Test When the Client Wants Everything by Friday
You are the lead tester on a new engagement. The client's CTO signs a statement of work that says 'full penetration test of all external and internal systems, delivered in 5 working days.' During kickoff you learn the estate is 3 external /24 ranges (roughly 600 live hosts), an internal /16 with about 1,400 servers, and a payment application that is PCI-DSS in scope. The client has one change-advisory window per month and no test environment. The CTO says the board expects a 'clean report' and asks you to 'just scan everything and flag anything red.' Your team has two testers available for the week. The contract has no clause about out-of-scope systems or testing windows.
1. What is the first thing you should do before any scanning begins, and why?
Read the worked answer
Re-scope and re-contract before touching the estate. The signed SOW is not achievable at the stated depth in 5 days with 2 testers, and it gives you no testing-window, out-of-scope, or contact clauses. Concretely:
- Quantify the mismatch for the client: 600 external hosts + 1,400 internal servers + a PCI app cannot be tested to a meaningful depth in 5 tester-days each. Scanning is not testing; the CTO is being sold a scan.
- Agree a risk-based sample (e.g. external: all internet-facing services on the 600 hosts; internal: the PCI app, domain controllers, and a representative sample of server tiers) and document the sampling rationale so the report's limitations are explicit.
- Add clauses: emergency stop contact, agreed testing windows aligned to the monthly CAB, and a list of explicitly out-of-scope systems (production payment switch, third-party hosted services).
- Get written confirmation of authorisation and the revised scope from the CTO.
Starting a scan against 2,000 hosts under an ambiguous SOW risks outage, scope disputes, and a report you cannot defend. Scope is a soft-skill and legal issue before it is a technical one.
2. The CTO pushes back and says the board only cares about 'red flags.' How do you handle this without simply agreeing?
Read the worked answer
Reframe rather than refuse. The board's real need is decision-grade risk information, not a colour. So:
- Offer a tiered deliverable: a short executive summary of confirmed high-impact findings by day 4, with the full technical detail following. This meets the board's timeline without pretending the whole estate was covered.
- Be explicit in the executive summary about coverage and confidence - what was tested, what was sampled, what was not touched. A 'no red flags' line on an untested estate is the most dangerous output you could produce.
- Explain the cost of a false clean: if an untested PCI segment is later breached, the report becomes evidence that testing was misrepresented.
This is the assessment-management judgement the exam rewards: protect the client from a misleading result, keep the relationship, and put the limitation in writing.