Subsidiary subnet discovered mid-engagement: scope, metrics or momentum?
Northwind Freight has contracted a three-week external and internal penetration test covering 1,850 assets across two /20 ranges plus a single Active Directory forest. The statement of work ties the test to PCI DSS v4.0 segmentation checks and states that the retest in 90 days will be scored "using the same methodology". On day 4, discovery from the internal jump host surfaces 10.42.0.0/16, which belongs to a subsidiary acquired eight weeks ago. Your client contact says: "It's probably fine, just look at it, we'll sort the paperwork later." Your team runs a documented Kali baseline image; a second tester joins on day 9 and has not worked with this client before. The CISO's stated success criterion is simply "fewer findings at retest", and your sponsor wants a defensible progress metric by day 10 that will survive an auditor's questions.
1. The subsidiary range is live and reachable but not in the signed scope. What do you do in the next 24 hours, and how do you protect the validity of the engagement metrics?
Read the worked answer
Do not touch it. Reachability is not authorisation. Send a written notification (email plus ticket) to the sponsor within 24 hours that records the discovery method, the timestamp, the exact CIDR, and the fact that no packets beyond discovery were sent.
Then make the scope change a decision, not a drift:
- Ask for a signed change order specifying ranges, testing windows, rules of engagement for the acquired estate (it likely inherits different data-handling rules), and whether the retest will include it.
- If it is added, it becomes a separate scope baseline with its own start date. Do not merge it into the day-1 denominator.
- If it is not added, log it in the report as "discovered, not tested" with the reason. Auditors accept a documented exclusion; they do not accept a silent one.
Why this matters for metrics: if you quietly expand scope, your asset denominator changes mid-engagement, your coverage percentage becomes meaningless, and the 90-day retest can never be compared like-for-like. It also creates a contractual and legal exposure: unauthorised testing of a subsidiary's network can breach the group's own insurance terms.
Practical bridge: you can keep testing the original estate at full pace while the paperwork moves, so the schedule only slips if the client wants subsidiary testing inside the same window - in which case negotiate the 90-day retest definition at the same time.
2. Design three metrics that will survive the 90-day retest and cannot be gamed by either the test team or the client.
Read the worked answer
Metrics need to be defined before testing, versioned, and frozen with the report.
1. Authenticated asset coverage Percentage of in-scope assets with a complete per-asset test record: host, open ports, service versions, credential tier used, tester initials, timestamp, and evidence reference. Target 100%, with a published exclusion list (e.g. OT devices). This cannot be gamed upward by running a scanner, because a record requires human-validated service enumeration and a credential tier. Measured identically at retest against the same asset inventory file.
2. Validated finding density with proof level Count findings normalised per asset class, each tagged with a proof level: P1 confirmed exploitation, P2 validated evidence without exploitation, P3 suspected. Severity uses a pinned CVSS version with full vector strings. This kills the classic gaming move - dumping 400 raw scanner hits to look thorough, or suppressing findings to look clean. A drop in P1 count between test and retest is a real, auditable improvement.
3. Remediation half-life on a fixed finding set Median days from report delivery to vendor-verified fix, computed only over the findings present in the original report, with "verified" meaning the test team re-tested it. Excludes new findings so the client cannot dilute the number by commissioning extra scope.
Add a process metric for your own quality: 10% of findings peer-reviewed by the lead before issue, with review recorded. That is what makes the numbers trustworthy rather than merely precise.
3. A second tester joins on day 9. What artefacts must already exist so that their results are comparable to yours and the retest stays like-for-like?
Read the worked answer
Comparability comes from artefacts, not from a briefing call.
Must exist before they touch a host:
- A versioned methodology document for this engagement: ordered phases, per-phase entry/exit criteria, and what "done" means for a host.
- Tool baseline: image hash, tool versions, scan policy files, wordlists, and any custom scripts under version control. A different sqlmap version with different defaults is a different methodology.
- Severity matrix: CVSS version plus any client-specific modifiers, written down with the rationale, so two testers score the same finding identically.
- Evidence schema: directory naming, screenshot rules (include URL, timestamp, request ID), redaction rules for personal data, and hashing for integrity.
- Credential tiers: exactly which account levels are authorised, and which findings require re-testing at each tier.
- A 30-minute calibration: have the new tester independently re-run three findings from days 1-8 and compare evidence and severity against the originals. Divergence reveals misunderstanding before it contaminates the dataset.
Also record: daily activity logs (host, time, action) so coverage claims are provable, and an escalation path in writing - who they call before any action with availability risk.
If any of that is missing on day 9, the honest move is to spend the day building it. An uncalibrated tester inflates the finding count, changes the severity mix, and quietly breaks the very comparison the CISO is buying.