Why judgement may become the defining skill in offensive security

Imagine reaching the point in a penetration test where the weakness is clear: one customer can access another customer’s sensitive information. You have the evidence. The automated workflow is ready to keep going, collecting more records and exploring related accounts.

What would another request tell you? It may answer an important question about the weakness. It may simply collect more customer data after you have already demonstrated the problem. That is a decision for the tester to make before continuing.

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 is the work of deciding what the evidence supports and what it is worth doing next. It means being clear about what you still do not know and what could happen if the decision is 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 can be a useful place to start. The next question is whether its assumptions fit what you observed, and whether another explanation would fit too. Thinking about the evidence that separates those explanations gives the next test a purpose.

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

The boundaries need to help someone decide what to do in the moment. A requirement to seek approval is useful only if the reviewer has the context and time to make that decision properly.

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.

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.

The activity record needs to be available to that reviewer. It lets them compare what the workflow actually did with what the team and client 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.

When tools take over those activities, a better-looking output can come with fewer chances for the tester to practise the reasoning. Keeping some supervised exercises gives people that experience, while automation can still help them explore alternatives and get 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 cross-customer access example. A short note before the next request makes the decision clear: what access have we demonstrated, what question remains, and why would retrieving another record answer it? The proposed action also needs to fit 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.