Solusec: Solutions for Cyber Security

Operated by Solusec Ltd
CREST accredited · IASME Certification Body

During the test

The tester has found something serious. What now?

The gap between finding a critical and you hearing about it is a window in which you are exposed and do not know it. It should be measured in hours, not working days.

Urgent penetration testing › A critical, mid-test

Most penetration tests find nothing that cannot wait for the report. Occasionally one finds something that can: an unauthenticated route to remote code execution, an exposed database, a way for any user to read every other user's records, credentials sitting in a public repository.

What happens in the hours after that discovery says more about a provider than anything in their marketing.

Why the default is wrong

The common process is that findings are collected during testing, written up afterwards, and delivered as a report five working days later. For most findings that is fine. For a critical it means you spend up to a fortnight exposed to something your supplier already knows about, for reasons entirely to do with their workflow.

If that flaw is exploited in that window, the fact that it was in a draft report on somebody's laptop is not a comfortable position for either party.

What should happen

  1. The tester stops and confirms. A suspected critical is confirmed minimally, with the least intrusive proof that establishes it is real. Confirming does not mean exploiting fully.
  2. You are told the same day. By phone to the named contact, not by email to a shared mailbox. The rules of engagement should name the person and the number.
  3. You get enough to act on immediately. What it is, where it is, what it allows, and the quickest safe mitigation. Not the full write-up, which can follow.
  4. You decide what happens next. Continue testing, pause while you remediate, or stop and treat it as an incident. That is your decision, not the tester's.
  5. It is written up properly afterwards in the report, with the timeline of when it was found and when it was reported.

The distinction between a finding and an incident

A critical vulnerability is a finding. Evidence that somebody has already exploited it is an incident, and the two need different responses.

Signs that shift a test into incident territory: web shells or unexpected scheduled tasks, accounts that nobody recognises, log gaps, outbound connections to unusual destinations, data staged for extraction. A tester who finds any of those should stop immediately and escalate, because continuing risks contaminating evidence you may later need.

Your rules of engagement should say this explicitly, with a named escalation contact. Discovering a live intrusion at five on a Friday is not the moment to work out who to ring.

What to have agreed in advance

The clauses that matter when it happens
ClauseWhat it should say
Notification thresholdWhat severity triggers immediate contact. Critical always; high usually.
Notification method and timeframePhone to a named person, same day, with an out-of-hours number.
Stop conditionsEvidence of prior compromise, instability, unexpected personal data.
Who decides whether to continueYou do. The tester advises.
Whether remediation pauses the clockIf you pause to fix, does the engagement resume without a new purchase order.
Evidence handling on escalationWhat the tester preserves and how, if it becomes an incident.

What not to do when you get the call

Do not rush a fix into production without a change record. The urge is understandable and the audit trail matters, particularly if this turns into an incident later.

Do not assume the tester is wrong. Ask for the reproduction steps and verify, by all means. Arguing with the finding before understanding it wastes the hours that matter.

Do not tell the tester to keep going as though nothing happened if there is any suggestion of prior compromise. Testing over the top of an active intrusion makes the forensics considerably harder.

Do not forget to check whether it is exploitable elsewhere. A flaw found on one system is often present on three.

What we commit to

Confirmed criticals are reported the day they are confirmed, by phone, with enough detail to start mitigating immediately. Evidence of prior compromise stops the test and escalates rather than continuing. Both are in the rules of engagement before testing starts, not offered as a courtesy afterwards.

It is a low bar and a surprising number of providers do not clear it. It is worth asking any provider directly: if you find something critical on Tuesday, when do I hear about it, and from whom.

Deciding whether to pause: a rough framework

You have had the call. Testing is ongoing. Do you let it continue, or stop it while you fix the finding?

Three questions settle it most of the time.

Is the flaw being actively exploited, or could it be while testing continues? If the tester found an unauthenticated route into a production system, that route was open before they arrived and is open to everybody else too. Fixing it becomes urgent regardless of the test, but it is not usually a reason to stop testing elsewhere.

Will fixing it change what the rest of the test finds? Sometimes yes. If the critical is a shared component or an authentication weakness that the tester would otherwise pivot through, remediating mid-test changes the environment underneath them and the remaining findings become hard to interpret. In that case, pause, fix, and resume with a clear picture.

Does the remediation itself risk instability? An emergency patch to a production system during an active test is two changes at once. If something breaks, nobody will be able to say which caused it. Where the fix is significant, pausing is simply cleaner.

If none of those apply, let the test continue and fix in parallel. The tester is working elsewhere and you lose nothing.

Agree the commercial position in advance

The awkward version of this conversation is not technical. It is discovering, on the phone, that pausing for four days to remediate means the engagement is rescheduled, the tester is on another job, and resuming needs a new purchase order.

One line in the engagement terms prevents it: if testing is paused at the client's request to remediate a finding reported by the tester, the engagement resumes within an agreed period at no additional cost. Most providers will accept that without argument, because the situation is rare and the goodwill is worth more than the risk.

Ask for it before you sign rather than when you need it.

How quickly should we be told about a critical?

The same day it is confirmed, by phone. Anything slower means you are carrying a known risk you do not know about, purely because of the supplier\u2019s reporting cycle.

Does the test stop while we fix it?

Your decision. Often it makes sense to continue testing elsewhere while remediation happens in parallel. Sometimes the finding changes the picture enough that pausing is right. Agree in advance whether pausing costs you anything commercially.

What if the tester finds signs we have already been breached?

The test should stop and escalate immediately. That is an incident, not a finding, and continuing to test over it makes forensics harder. Your rules of engagement should name an escalation contact for exactly this.

Do we have to report it to the ICO?

A vulnerability is not a breach. Discovering a flaw that could have allowed access to personal data is not by itself notifiable. Evidence that it was actually exploited may well be, and that is a decision to take with your own legal advice quickly, since the clock is short.

Criticals reported the same day

Every engagement includes same-day notification of confirmed criticals, by phone, agreed in writing before testing starts.