Out-of-Scope Subsidiary, PII in Screenshots and a Disputed Rating
You are writing the final report eight days after the last test day for a client whose external estate you assessed for two weeks. Three problems have surfaced.
First, alongside a shared wildcard certificate you observed portal.partner.example, hosted in the same /24 but owned by a different legal entity - a subsidiary that is not named in the statement of work. The banner shows a framework version with known critical vulnerabilities. You did not test it and did not authenticate; you only read the HTTP response headers.
Second, a screenshot of the application's admin console, taken to evidence an access-control failure, includes 43 real customer records with full names and partial card numbers.
Third, the client's IT manager disputes your High rating for SMB signing not being required on several servers, arguing that "it's internal only, and nobody can get in there anyway". He wants it changed to Low before the report goes to the board.
1. How do you treat the subsidiary host in the report?
Read the worked answer
The host is out of scope, so the report must be written so it cannot be read as a claim that you tested it.
- Facts only, framed as an observation. Record what a passive request to a public endpoint returned: the URL, the banner, the timestamp, and an explicit sentence that no testing, authentication or exploitation was performed. Do not include payloads, version-specific exploitation guidance or a step-by-step reproduction, because that would turn an observation into a roadmap for a system nobody has authorised you to assess.
- No asserted severity. "Potential, unconfirmed, scope unknown" is the honest label. You have a version string, not a vulnerability, and you cannot know the subsidiary's compensating controls.
- Route it through the client sponsor, in writing, on the day you find it. They decide whether to notify the subsidiary and whether to authorise an extension of scope. Do not contact the subsidiary directly - you have no contract with them, and doing so is the fastest way to create a legal problem for your client.
- Note the scope discrepancy as a finding about the client's own asset inventory: a shared wildcard certificate spanning a different legal entity is a governance issue they can act on.
Recommend the subsidiary commission its own assessment, and log the notification so the report can state when the client was informed.
2. What do you do with the screenshot containing customer records?
Read the worked answer
You are holding personal data you have no need for, which creates an obligation independent of the security finding.
- Do not put it in the report. The purpose of the evidence is to show that the console was reachable and that records were displayed; a crop showing column headers and the count of visible rows, with values masked, discharges that purpose completely. A single unmasked row is enough to demonstrate the failure; 43 is unnecessary.
- Handle the original as controlled data. Keep it only in the encrypted evidence store, restrict access to the named testers, and record who accessed it. Note the retention and destruction date in the contract and honour it - purge it when the retest closes unless the client asks for longer.
- Tell the client promptly. They may have their own breach-assessment and notification duties, and they cannot assess them if they learn about the exposure when the report lands three weeks later. Flag it in the same message as the subsidiary notification, as a data-handling note rather than a finding.
- Adjust the method for the rest of the work. Where a screenshot would capture live records, capture structure only, or use a test record the client created for the purpose.
Redaction is not hiding a finding; it is minimising data, and the report should state that redaction was applied and why.
3. How do you handle the disputed High rating for SMB signing?
Read the worked answer
Treat the disagreement as a methodology conversation, then let the risk owner decide - in writing.
- Show the scoring inputs. CVSS base, then the contextual modifiers: exposure (reachable from which segments, how many hosts), the threat-model scenario it feeds (credential relay and lateral movement), whether the control is actually absent or merely misconfigured on some hosts, and the audit trail of what you verified.
- Test the manager's premise. "Internal only" is an assumption you can check against the data you already hold: how many hosts, which segments, and whether any path from a lower-trust zone reaches them. If segmentation is real and enforced, credit it in the rationale - that reduces likelihood, but SMB signing absent on servers is still rated for the relay path it enables, and the board should see both facts.
- Do not silently downgrade. If the client, as risk owner, maintains a different rating, publish yours with the reasoning and add a short note recording their position and rationale. That protects them and you, and it is the accurate record.
- Offer a route to closure. State exactly what a retest would need to see to justify a lower rating - signing required by policy on the named hosts, verified by configuration output.
Finally, make sure the executive summary separates technical severity from business decision: the board needs the sentence about what an attacker does with the gap, not the CVSS vector.