Peer review, escalation paths and articulating risk

Objective 1.3 in this course covers collaboration and communication — CompTIA describes it as aligning with stakeholders through peer reviews, escalation paths and risk articulation.

Why this matters

This is the objective people skim, and it is disproportionately represented in scenario questions — because it is the one where the right answer is a judgement, and judgement is what a multiple-choice exam can test cleanly when the alternatives are all technically possible.

It is also the difference between a tester who gets rehired and one who does not. Clients rarely change supplier because the testing was insufficiently clever. They change because nobody told them something in time, or because a report landed that made their team look incompetent in front of their board.

The lesson

Who receives which finding, and when

Not every finding goes to everyone, and not everything waits for the report.

The people involved usually fall into four groups, and they need different things:

• The engagement sponsor — signed the contract, wants to know it is on track and whether anything changes the risk picture.
• The technical contact — will receive the findings and has to fix them. Wants detail, and wants it early enough to start work.
• System owners — may not have known a test was happening. Are the people whose weekend you ruin if you report late.
• Legal, compliance or privacy — get involved when regulated data or mandatory reporting is in play.

Agree the routing before the engagement, and default to the technical contact first for anything actionable. Sending a critical finding straight to an executive without warning the engineer is how you make an enemy of the one person whose help you need.

Escalating a critical finding without blowing up the engagement

Some findings cannot wait. Lesson 4 covered the ones with a legal obligation; this is the larger category of things that are simply too serious to sit in a document for three weeks.

The test to apply: if the client knew what I know right now, would they want to be woken up? An unauthenticated path to customer data from the internet passes that test. A missing security header does not.

When escalating, four things make it land well:

1. Go through the agreed path, which you established before starting. Not whoever you happen to have a phone number for.
2. Lead with the impact, not the technique. "Anyone on the internet can read your customer database, and here is the proof" — not the CVE number.
3. Say what you have and have not done. Whether you stopped, whether you still have access, whether you took data.
4. Offer the immediate mitigation, even if it is ugly. A firewall rule tonight and a proper fix next month is usually the right shape.

What makes escalation blow up an engagement is surprise — a finding arriving sideways, to the wrong person, with no context, sounding like an accusation.

Peer review that catches a wrong severity before the client sees it

Peer review is cheap and it is the last thing to survive a deadline. Protect it, because the failure it catches is the expensive kind.

A useful review asks three questions of each finding:

• Is it reproducible from what is written? If the reviewer cannot follow it, the client's engineer cannot either.
• Is the severity defensible? This is the most valuable catch. A reviewer with no emotional investment is the person who will say "this is a medium and you have called it critical", before the client does.
• Does the impact statement match the evidence? Overreach creeps in while writing — a finding that proves file read gets described as full compromise because that is where it could lead.

The point is not that the reviewer is more senior. It is that they have not spent two days getting attached to the finding.

Talking about risk to people who do not think in CVSS

A CVSS score is a common language for practitioners and meaningless to almost everyone else. Translating it is part of the job.

What works:

• Describe the consequence, not the mechanism. "An attacker could place orders as any customer" lands; "IDOR on the order endpoint" does not.
• Say who could do it and what they would need. Anyone on the internet with a browser is a very different risk from an authenticated user with insider knowledge, and the score alone hides that distinction.
• Anchor to something they already worry about. Most organisations have a risk they already take seriously; positioning relative to it is more useful than an absolute number.
• Give them a decision, not a feeling. "Fix this before the launch" is actionable. "This is very serious" is not.

Avoid the two failure modes: inflating everything to be taken seriously, which stops working the second time, and hedging so carefully that a critical finding reads as routine.

Disagreeing with a client who wants a finding downgraded

It happens, and it is not always illegitimate. Sometimes the client knows something you do not — a compensating control, a decommission date next month, a system that holds nothing real.

So the first move is to listen for new information, and if there is any, your severity was based on an incomplete picture and should change. That is not capitulation; it is the assessment improving.

If there is no new information and the request is simply that the number look better, the answer is no, and the way to say it is:

• State the basis, which you wrote down when you set the severity.
• Offer to record their position in the report alongside yours. A finding that notes "the client assesses this as lower risk because…" is honest, and it often satisfies what they actually wanted.
• Do not quietly change it. A severity edited under pressure and not explained is the thing that, after an incident, makes every other finding in the report suspect.

Your name is on the document. It has to say what you found.

What to take into the exam

• Route findings to the technical contact first for anything actionable; agree the path before the engagement.
• Escalate on impact, through the agreed path, with the immediate mitigation.
• Peer review's highest-value catch is an indefensible severity.
• Translate risk into consequence, actor and decision — never a bare score.
• New information can change a severity; pressure cannot, and the disagreement gets recorded rather than hidden.