How poor scoping damages penetration testing delivery

The API test is booked for next week. The proposal mentions the user roles, but when the tester opens the handover, there is only an administrator account. In this hypothetical engagement, checking access between ordinary users was part of the work the client expected.

The tester can start some work. They cannot complete the planned authorisation checks without suitable accounts and data. Someone now needs to agree whether the client can supply them in time and what happens to the booked days if it cannot.

By then, the team is trying to solve an access problem against a running clock. Getting that dependency into the scope earlier gives both sides time to resolve it or change the booking.

Estimate the work behind the asset count

Calling something one application tells the tester very little about the work inside it. A single API can have several permission boundaries and workflows, each needing different accounts. A small application can still need substantial business-logic testing.

Ask the client to explain the relevant workflows and demonstrate the main functions where possible. Establish the purpose of the engagement. A release deadline may constrain the available time, while a specific assurance requirement may determine which workflows need attention first.

The resulting estimate should state the coverage that is realistic within the proposed time. Include restrictions that affect the depth of testing, especially where fragile systems or production data limit what can be attempted.

The CREST Guide to Penetration Testing recommends a formal scope supported by defined reporting requirements. Those agreements need enough detail for the assigned tester to understand the work being sold.

Confirm the prerequisites

The exact checks depend on the engagement. A practical readiness record can cover:

• Working credentials for the agreed roles, with suitable accounts on each side of any access boundary being tested.
• Representative test data and permission to use it.
• The correct environment, including any production restrictions.
• API documentation or other information needed to exercise the agreed functions.
• Known rate limits or monitoring that could interrupt testing, with an agreed response.
• A client contact who can resolve access and operational problems during the test window.

For each missing item, someone needs to know it is theirs to resolve and by when. A credentials request is a useful first step; checking those accounts in the intended environment before the booked start gives you much more confidence that the team can use them.

Some conditions will change after that check. The scope should still make the assumptions visible so both sides can recognise when the basis of the booking has changed.

Give delivery the information used to price the work

Some of the most useful context never makes it into the signed proposal. The sales conversation may explain which workflow worries the client most, or why a particular restriction was agreed. Passing that on helps the tester make sense of the assignment.

A handover should include the agreed coverage and exclusions, with the assumptions used to estimate effort. Identify outstanding dependencies and the people who can resolve them. Explain what the report is expected to address and which conclusions the planned work cannot support.

Sales and delivery need a way to resolve disagreement before the proposal is accepted. If an endpoint list has been described as a small test but delivery identifies several complex permission models, revise the estimate or agree narrower coverage with the client.

On a fixed-price engagement, unpriced complexity becomes additional effort unless the parties agree a change. Recording that effort against the project helps the business recognise recurring estimation problems.

Keep changes visible during testing

New information is expected during a penetration test. When it changes the agreed work, record the effect and involve the person authorised to agree a change with the client.

Distinguish an unexpected technical result from a missing prerequisite. The first may be part of normal investigation within the allotted time. The second may prevent an entire part of the scope from being tested.

A tester may be tempted to make up the difference by working late or quietly dropping coverage. That leaves the client unaware of what changed and the business unaware of the cost. Bring the choice into the open so the client understands the proposal and the business can agree how to handle any extra effort.

Decide what happens when access is unavailable

Return to the API example. The team should identify which work can proceed with the administrator account and which checks remain blocked. The client then needs a clear choice based on the time required to supply the missing access.

If the client accepts reduced coverage, document exactly what will remain untested and carry that limitation into the report. If the team can complete the blocked work with additional time, agree the fee and revised dates before undertaking it. If the missing access prevents the test from meeting its objective, move the test under the agreed booking terms.

The useful outcome is a decision both sides understand: what can be tested, when it can happen and what the price allows for. Put it in writing for the tester, so the report can give an accurate account of the work performed.