Penetration Testing Hub › Penetration Testing Explained
What to Expect From a Penetration Test
This page describes the buyer's experience of a test rather than teaching techniques, but the principle behind it all still holds: a legitimate test only ever runs against systems the client owns or has authorised in writing, under the Criminal Justice (Offences Relating to Information Systems) Act 2017.
The first pentest is where most of the anxiety lives — will it break something, how much of our time will it take, what will we get at the end? None of it should be a surprise. Here's the whole thing, stage by stage, so you know what you're signing up for before you sign.
Before it starts: scoping
You'll have a scoping conversation where you decide, together, what's being tested and what isn't. Expect to be asked: which systems, IP ranges, apps or networks are in scope; what's strictly off-limits; whether it's black box (tester knows nothing), white box (full access and docs) or grey box; when testing may happen; and who the emergency contact is. This gets written into a rules of engagement document that both sides sign. If a provider skips this, that's a red flag.
What you'll need to provide
- A named point of contact who can answer questions and make quick decisions.
- For internal or white-box testing: network access (a drop or a placed device/VM) and any credentials agreed.
- For web/app testing: test accounts at the relevant permission levels, and ideally a staging environment.
- An agreed testing window if any part of the work could affect live users.
- Written authorisation — especially if the systems are hosted by a third party, whose permission you may also need.
Timing
A typical engagement runs one to three weeks from kick-off to final report. The active testing is often only a few days of that; the rest is scoping, reporting, and scheduling the re-test. Bigger or multi-target scopes take longer. Beware anyone promising a thorough test of a complex environment in a single day — that's a scan wearing a costume.
Production risk — the honest version
A well-scoped test carries low risk, but not zero. Enumeration and most reconnaissance are safe. Active exploitation, testing of fragile legacy systems, and anything touching OT or production databases carries more risk, which is exactly why those are named in the rules of engagement and often run in a maintenance window. A good tester uses the least destructive proof that confirms a finding, and stops to check with you before anything that could cause an outage. Anyone who tells you there's no risk at all is either inexperienced or overselling.
During the test
For most of it, you won't notice much — good testing is quiet. You may get occasional check-ins, especially if the tester finds something serious enough to flag immediately rather than waiting for the report (a critical, actively-exploitable issue shouldn't sit in a queue for two weeks). Keep your contact reachable.
The report
This is what you're actually paying for. A good report has:
- An executive summary in plain language your board can read — the story, the risk, the priorities.
- A technical findings section, each rated by severity (usually CVSS), with enough detail for your engineers.
- Reproduction steps so your team can see each issue for themselves.
- Prioritised remediation — what to fix first, and how.
- Ideally, the attack chains that mattered most, not just an unranked list.
We publish a sample report so you can see the standard before you buy. If a prospective provider won't show you a redacted sample, ask why.
After: remediation and re-test
You fix the findings; the tester confirms the fixes actually worked. This re-test is the part buyers most often forget to ask about, and the part that turns a report into improved security. Clarify up front whether it's included and how long you have to remediate before it.
What you should not accept
- A report you can't understand, or one with findings but no fixes.
- No rules of engagement, or no signed authorisation.
- A 'test' where no human attempted exploitation.
- A sales pitch where the executive summary should be.
- No re-test, or no debrief call to talk through the findings.
Common questions
What happens during a penetration test?
Typically: scoping and rules of engagement, then reconnaissance, scanning, exploitation and post-exploitation, finishing with a report and a remediation re-test. You'll be asked what's in scope, what access to provide, and what must not be touched. Most engagements run one to three weeks depending on size.
Will a penetration test disrupt our business?
A well-scoped test is low-risk, and most of the work is quiet. The riskier parts — active exploitation, fragile or legacy systems, anything in production — are identified in advance and usually run in an agreed window, with a contact who can pause things. Zero risk can't be promised, which is why scoping matters.
What's in a penetration test report?
An executive summary in plain language, technical findings rated by severity, clear reproduction steps, and prioritised remediation advice — ideally with the key attack chains and a re-test. A good report is readable by both your board and your engineers.
If this sounds like what you need, here's how a CyberLabs engagement works from first call to re-test — scoping, a signed rules-of-engagement document, a testing window that suits you, and a report you can actually use.
No prices on this page and no hard sell.
This page is educational and not legal advice. Only test systems you own or are explicitly authorised to test. · ↑ Back to top