Authorized security testing

Pentest Preparation

A penetration test is an authorized attempt to get around a system's security controls. The tester may use methods that a real attacker would use. But the work has a defensive goal, a written scope, and clear safety limits.

Good preparation makes the result useful. The owner and tester need to agree on the question, authority, scope, rules, and next steps before testing starts.

A pentest answers a bounded question

A pentest cannot answer the broad question 'Is this system secure?' It can answer a narrower one. Can a normal user access another customer's data? Can a compromised account reach admin functions? Can an exposed service lead to sensitive data?

A vulnerability scan checks for known patterns across many systems. A pentest uses tools and human judgement to explore likely attack paths inside an agreed boundary.

That boundary is not just paperwork. It is what makes the test authorized. Anything outside the written rules stays outside the test, even when it is technically reachable.

The useful output is clear evidence, practical fixes, and lessons for future work. A dramatic finding is not enough if nobody knows how to handle or fix it.

How a penetration test is prepared and delivered

The legal and operational boundaries must be as clear as the technical target. The steps below cover the path from the first question to the retest.

01 · Define the decision
State why the test is being commissioned and what decision the result must support: a release, customer assurance, a material architecture change, or an independent check of internal vulnerability management.
02 · Confirm authority
Identify the owners of every target and obtain explicit written authorization. Cloud, hosting, payment, identity, and other third-party services may have separate policies or approval requirements. Owning one application does not mean you may test every dependency.
03 · Build the scope
List applications, APIs, hostnames, addresses, environments, roles, and important data flows. Record exclusions and shared infrastructure. A scope should describe assets and trust boundaries, not rely on a single homepage URL.
04 · Agree the rules
Document dates, hours, permitted test types, rate limits, prohibited actions, stop conditions, source addresses, communication channels, and how any scope change is approved. Denial-of-service, social engineering, persistence, and destructive actions stay excluded unless expressly authorized and controlled. If genuine adversary activity is suspected, pause the affected test and follow the incident-response path.
05 · Prepare access and safety
Provide representative test accounts and role descriptions, accurate documentation, safe test data, and a technical contact. Decide whether production or a representative environment is appropriate, check backups and monitoring, and prepare a rollback or containment path for unexpected impact.
06 · Protect evidence
Agree how credentials, customer data, screenshots, request traces, exports, and the report will be minimized, encrypted, shared, retained, and destroyed. Test evidence is often sensitive enough to become a security problem of its own.
07 · Test with checkpoints
The provider performs the agreed assessment and keeps the named contact informed. Critical findings and operational problems follow an immediate escalation path; discoveries outside scope are reported for a decision, not silently pursued.
08 · Report and debrief
Expect an executive summary, exact scope and limitations, methodology, reproducible evidence for each validated finding, contextual risk, affected assets, and actionable remediation. Anything that could not be safely validated should be separated, labelled unverified, and accompanied by the reason and uncertainty. A debrief lets developers and risk owners challenge assumptions and ask for clarification.
09 · Remediate and retest
Assign owners and deadlines, fix root causes, and regression-test related paths. A retest verifies the agreed findings against a later version; it does not repeat the whole engagement or prove that no other weaknesses exist.

Choose the assessment that matches the need

Security services overlap, but they answer different questions. Clear names prevent a team from buying one kind of evidence and expecting another.

Vulnerability scanning

Automated, repeatable discovery of hosts, configuration signals, and known vulnerabilities. It is useful for broad and frequent coverage, but results need validation and usually do not show how weaknesses combine in the application's business context.

Penetration testing

A time-bound assessment combining tools and human analysis to test whether weaknesses can bypass controls or create meaningful impact within a named scope. It is deeper and more intrusive than routine scanning, but still only a sample.

Security review

A broader examination of requirements, architecture, configuration, controls, or operating practices against defined risks or standards. The term is not one fixed methodology, so the statement of work must say which artifacts and environments are actually reviewed.

Code review

Source-assisted analysis of how security decisions are implemented. It can reveal unsafe data flows, missing authorization, and logic flaws, but its conclusions are limited to the code and context supplied and do not prove the deployed configuration behaves the same way.

Red teaming

An objective-led exercise that emulates a relevant threat actor across people, process, and technology to assess prevention, detection, and response. It is not normally designed to enumerate every vulnerability in one application.

Incident response

Work performed because a harmful event has occurred or is suspected: confirm impact, contain it, preserve evidence, eradicate the cause, and recover safely. A scheduled pentest can test controls; it is not a substitute for responding to a live incident.

Questions to settle before the test

A credible provider should help refine these answers and explain any trade-offs before the start date, not discover them halfway through the engagement.

What exact question will the test answer, and which risks are most important to us?
Which named tester will do the work, and what relevant experience, qualifications, or required accreditations can the provider demonstrate?
Which methodology and coverage will be used, and what will not be tested?
Which accounts, documentation, source code, architecture context, or previous scan results would improve the assessment?
Which actions are prohibited, rate-limited, or require a fresh approval?
Who is reachable during testing, and how quickly will a critical finding or service impact be escalated?
How will evidence and credentials be protected, retained, returned, and destroyed?
What report, debrief, remediation support, and retest are included in the agreed price and schedule?

Example: scoping a small SaaS application

A small team is preparing an invoicing platform for its first enterprise customer. It wants independent evidence about tenant isolation and administrative access before release. The objective is not 'test our company'; it is to assess whether an internet user or ordinary tenant member can reach another tenant's records or privileged functions in the release candidate.

The scope names the web application, public API, authentication flow, and administration portal in a staging environment that matches production configuration. The team supplies synthetic data and accounts for an administrator, a standard member, and a suspended member. The production payment provider, corporate email, employee accounts, denial-of-service, and social engineering are explicitly excluded; the team confirms that no shared third-party infrastructure may be tested without separate permission.

The rules set working hours, source addresses, a request-rate ceiling, emergency contacts, and an immediate notification path for cross-tenant access or service instability. The team verifies backups and logging, agrees that evidence will be encrypted and deleted after the retention period, and schedules a developer for short-notice questions.

The report identifies a cross-tenant authorization flaw with reproducible evidence and a server-side remediation. The team fixes the shared authorization helper, adds regression tests across all roles, and requests a retest. The retest confirms that this finding is no longer reproducible in the new build; it does not convert the original, bounded assessment into a guarantee about the whole platform.

Common scoping and interpretation mistakes

Engagement quality can be lost before technical testing starts or after the report arrives. These mistakes reduce safety, coverage, or the chance that findings will be fixed.

Testing without complete authority

Permission from an application owner may not cover the hosting platform, shared network, supplier, customer data, or another legal entity's assets. Resolve ownership and provider policies before any activity.

Writing 'test everything' as the scope

An undefined scope hides assumptions about environments, APIs, roles, mobile clients, and third parties. It also gives neither side a reliable basis for time, safety, coverage, or price.

Buying a scanner report as a pentest

Automation can support broad, repeatable discovery, but a penetration test also needs contextual analysis, careful validation, and human exploration of relevant paths. Ask who performs that work and how it appears in the report.

Testing production without preparation

Testing production can provide evidence from the real operating context, but it can affect availability and real data. Decide deliberately, involve operators, minimize risky actions, and keep stop and recovery paths ready.

Treating the report as a certificate

A report describes what was examined and observed under stated constraints. A clean result may mean no issue was found in that sample; it does not mean no issue exists.

Fixing findings without retesting the cause

Changing the exact line shown in evidence can leave the same authorization or validation flaw elsewhere. Remediate the shared cause, add regression coverage, and define what the retest will verify.

Authorization, coordination, and ownership

The system owner remains responsible for the test and its risks. A provider can suggest the scope, rate findings, and explain fixes. It cannot expand its own authority or decide which risk the organization should accept. Every target and activity needs approval from someone who is allowed to give it. Use a signed scope or contract and seek legal advice where needed.

A pentest is a sample from a specific point in time. Its value depends on the scope, access, environment, time, method, and tester. A confirmed finding proves a weakness under those conditions. Missing findings do not prove that no other weakness exists.

Treat the report and evidence as sensitive data. Give fixes clear owners and priorities. A retest should name the findings, version, and date it covers.

Authorize every target and activity in writing
Name technical and risk-owner contacts
Record exclusions as explicit limitations
Escalate critical findings and service impact immediately
Protect and destroy evidence on an agreed schedule
Track remediation and retest scope separately

Key takeaways

01Start with the decision the test needs to support.
02Get written authorization and agree on scope and rules before testing.
03Choose the type of assessment that fits the question.
04Prepare accounts, contacts, safe data, monitoring, and evidence handling.
05Require clear proof, limits, context, and practical fixes in the report.
06Treat the result as a dated sample, fix root causes, and retest agreed findings.

Sources and further reading

A compact selection of primary sources, standards, and public technical guidance used to ground this article.