Planning penetration testing: scope, process and costs
A penetration test examines authorised systems from an attack perspective. Useful results for your operation matter more than the largest number of findings. Describe objectives and boundaries so providers quote for the same work. A test covers a defined period and scope; subsequent changes and untested areas require separate consideration.
Connect testing to a concrete decision
A launch, a substantial change and verification of remediated findings call for different work. Identify the decision the result should support and the business workflows that matter. An automated vulnerability scan and a manual penetration test have different depths.
A list of weaknesses does not itself explain their impact. Ask for relevant relationships to be examined, including roles and access rights. A complete organisational audit or certification is not automatically part of the test.
Set clear target boundaries
Count applications and network targets separately. Additional roles, interfaces and complex workflows may take more effort than another simple host. Define what each target includes rather than comparing an unexplained number.
| Test area | Clarify in the quote |
|---|---|
| Web application / API | Applications, roles, interfaces and important workflows |
| Internal / external network | Authorised hosts, networks and reachable services |
| Cloud configuration | Accounts, responsibilities and explicit authorisation |
| Mobile application | Platforms, versions and connected services |
Agree authorisation and rules before starting
The engagement must explicitly authorise testing of the relevant systems. Clarify third-party platforms and outsourced services: using a service does not automatically permit testing all its infrastructure. Exchange detailed target lists and any required access later through an agreed secure channel.
Agree testing windows, excluded methods, load limits, emergency contacts and stop rules. Availability testing, social engineering and other special methods need explicit agreement. A quote request does not yet authorise technical testing.
Choose information and environment deliberately
An external test with limited knowledge and a test with defined accounts or architectural information have different priorities. Ask why the proposed approach fits your objective. Giving less information does not automatically produce a more thorough assessment.
A test environment may reduce operational risks if it represents relevant configuration. Production requires particular care with safeguards, observation and coordination. Prepare neutral example data and suitable test accounts without submitting real customer records in the enquiry form.
Require a usable report
The report should state scope, dates, methods and limitations. Confirmed findings need understandable evidence, affected components, impact and remediation guidance. A clear summary and technical detail can serve different audiences.
Prioritise the actual risk in your environment. Finding counts or a single technical severity score do not replace that assessment. Agree confidential transfer, retention and deletion of test material, plus responsibility for urgent notifications.
Compare equivalent depth and deliverables
Costs depend on targets, complexity, available information, manual depth and documentation. Separate preparation, testing, reporting, discussion and retesting. A scan quote may cover less work than a detailed examination of business logic.
Compare the same systems and exclusions. Clarify additional targets, unexpected obstacles and rescheduling. Remediation and ongoing monitoring are separate services unless expressly included.
| Cost item | Comparable scope |
|---|---|
| Preparation | Target definition, authorisation and test access |
| Testing | Manual depth, roles, systems and time windows |
| Results | Report, prioritisation and discussion |
| Retesting | Which corrected findings and agreed timeframe |
| Additional work | Expansion, remediation and further tests separately |
Handle findings and verify changes
Assign important findings to an owner and track remediation. A retest checks agreed corrections; it is not automatically a fresh examination of every system. Agree scope and evidence in the quote.
An initial enquiry needs the objective, target types and numbers, environment and timing. Substantial changes, new interfaces and operational risks may warrant reassessment. An earlier report describes the bounded state examined at that time.
Frequently asked questions
Is a scan the same as penetration testing?
A scan detects certain known patterns. A penetration test can also examine relationships and impact manually. The expressly agreed scope makes the difference.
Can production be tested?
It may be appropriate with agreed windows, safeguards and stop rules. Disruption-free testing cannot be guaranteed generally.
Does a favourable result prove complete security?
No. It relates to the agreed scope and time. Untested areas, new weaknesses and later changes remain possible.
Is certification included?
A test report is not automatic certification. Agree the criteria, scope and recognition of any specific assurance required.
Should I submit passwords in the enquiry form?
No. A non-confidential description is sufficient. Necessary test access is agreed separately and exchanged securely after authorisation.
When is retesting useful?
After important findings have been remediated. Agree which corrections are checked and whether wider testing is needed separately.
