Why judgement may become the defining skill in offensive security

Consider a hypothetical penetration test. A tester has demonstrated that one customer can access another customer’s sensitive information. The evidence is clear. An automated workflow offers to continue, collecting more records and exploring related accounts.

Before continuing, the tester needs to identify what another request would establish. Collecting more records may expose additional customer data without resolving anything still uncertain about the weakness.

If the existing result answers the agreed testing objective, the tester can stop and record the limitation on the evidence collected. If a material question remains, a bounded follow-up test may be justified within the authorised scope.

That decision requires technical understanding as well as a reason for taking the next action. As automation handles more execution, deciding where to spend the remaining test time may become a larger part of the tester’s job.

What judgement means in offensive security

Professional judgement involves deciding what the available evidence supports and what further work is justified. The decision needs to account for what remains uncertain and the consequences of getting it wrong.

It appears throughout an engagement: deciding which attack path deserves attention, whether an unexpected result is meaningful, how much evidence is sufficient and when to involve someone with different expertise.

It also shapes conclusions. A plausible attack path is not necessarily a demonstrated compromise. A technically serious weakness may have consequences that depend on controls the tester has not yet examined. The practitioner needs to recognise those distinctions and explain them.

This is particularly visible when pentest teams handle severity disputes. Good judgement includes changing a conclusion when new evidence warrants it, while resisting pressure to change one without a sound reason.

Experience can help a tester recognise a familiar situation. They still need to check that the assumptions fit this engagement and revise them when the evidence changes.

Why automation could change the balance

If automation makes more technical execution readily available, the ability to perform an action may become a weaker differentiator between practitioners. Greater weight could fall on choosing the right action and understanding its result.

A tool might generate several promising avenues of investigation. The tester needs to check the assumptions behind them and choose which one addresses the engagement objective. Pursuing every possibility can consume the time needed to investigate the most consequential one properly.

The change will be uneven. Specialist research and unfamiliar environments can still demand considerable original technical work. Those engagements may continue to spend much of their time developing and testing an approach before automation can help.

Curiosity and technical depth still matter

A tester needs curiosity to investigate an unexpected result and enough technical depth to evaluate possible explanations. Without understanding the system, they may overlook a security boundary that the automated test never exercised.

A convincing initial answer still needs examination. Check its assumptions against the observed behaviour and consider whether another explanation fits. Identify the evidence that would distinguish those explanations.

A practitioner who accepts fluent output without checking its basis may carry an unsupported assumption into the report. Equally, a technically capable practitioner who pursues an interesting route without considering its relevance can lose sight of the engagement’s purpose.

Reviewers should expect the tester to explain the system behaviour behind a finding. That technical explanation is necessary to assess whether the tool’s conclusion follows from its evidence.

Deciding what to delegate is part of the job

Before testing begins, agree what the automated workflow can do and which actions need review before execution. Identify how its results will be verified.

Those arrangements should reflect the environment and the consequences of error. Organising notes presents different concerns from running a workflow that can change production data. Agree:

• the objective and authorised boundaries of the delegated work
• the evidence needed to trust its outputs
• the conditions that require a pause or escalation
• who can approve a change and who reviews the outcome

Those boundaries should be practical enough to guide behaviour. Requiring approval without giving the reviewer sufficient context or time provides little assurance.

Further investigation is appropriate when the current evidence cannot support a necessary conclusion and the proposed action is authorised. Define what the action would establish before running it.

Accountability needs people who can explain the decision

Assign responsibility for reviewing automated work and handling problems during the engagement. The client needs a named person who can explain a decision and arrange any correction it requires.

The NIST AI Risk Management Framework’s governance guidance calls for defined responsibilities, executive responsibility for AI risk decisions and policies covering human oversight. This is voluntary risk-management guidance, rather than a universal legal requirement for a human to approve every action.

CREST’s principles for AI-enabled activities, updated in May 2026, place oversight with suitably competent personnel who can review outputs, challenge decisions and intervene when needed. They also call for AI activity to remain within defined controls and, where relevant, client-agreed scope. For the testing team, the agreed controls need to be specific enough that a reviewer can identify when a workflow should stop.

Give the reviewer access to the workflow’s activity record, so they can compare what ran with what was authorised.

The reviewer also needs to explain the decision to the client, including any limits on the evidence. The consulting skills article follows a client challenge through that conversation.

Preserve practice in making decisions

Teams need to decide which supervised tasks to retain as automation takes over more of the work used to train testers.

Investigating an inconsistent result gives a tester practice in choosing what to check next. Writing it up and discussing the reasoning with a reviewer can then expose an assumption they did not know they were making.

If tools take over those activities, the output may improve while opportunities to practise the underlying reasoning shrink. Supervisors can retain those exercises while using automation to help testers explore alternatives and obtain feedback.

This builds on how AI changes the junior pentester role, but the issue extends to experienced practitioners working in unfamiliar environments.

Teams can preserve useful learning deliberately:

• Ask testers to propose a next step and explain their reasoning before comparing it with a tool’s suggestion.
• Keep supervised hands-on testing in development plans, including uncertain and misleading results.
• Review a decision after an engagement, including a case where the tester stopped because they had enough evidence.
• Use a short scenario where the client’s request conflicts with an operational restriction.

Choose exercises that let a supervisor observe the tester’s reasoning. Once someone can evaluate that work independently, adjust the supervision to match.

Use the tester’s work to choose the development response. Pentest QA can provide evidence for that choice when reviewers examine the reasoning and discuss it with the tester.

Record the decision before continuing

Return to the example of cross-customer access. Before allowing the workflow to retrieve more records, the tester should record the access already demonstrated and identify the question that remains unanswered. The note should explain why another request is needed and confirm that it falls within the agreed scope and data-handling limits.

If further testing requires a change to those limits, pause and obtain the required authorisation. If the existing evidence is sufficient, stop the collection and explain in the report what was observed and what was not tested.

A reviewer can then assess the decision against the information available at the time. Keeping that record gives the team a specific example to use in supervision, including when the appropriate decision was to stop.