Penetration Testing
A penetration test answers a question a scanner cannot: not whether a weakness exists, but whether it can actually be used to reach something that matters. All testing is authorised in writing before it begins, with an agreed scope, a testing window and named emergency contacts on both sides.
1
Scope
Written authorisation and boundaries
2
Discover
Map the reachable attack surface
3
Exploit
Prove the weakness is real
4
Escalate
Establish what it reaches
5
Report
Evidence and prioritised fixes
How We Test
01
Scoping and Authorisation
Nothing starts without a signed scope. We agree which systems are in and out, the testing window, how far exploitation may go, and who to call if something behaves unexpectedly. Where systems are hosted by a third party, their written consent is obtained as well.
- Written scope and rules of engagement
- Testing window and change freeze considerations
- Named emergency contacts on both sides
- Third party hosting consent where applicable
02
Reconnaissance and Discovery
We map what is actually reachable, which is regularly more than the inventory suggests. Forgotten subdomains, test environments left exposed and services nobody remembers enabling are common starting points.
- External footprint and subdomain enumeration
- Service and version identification
- Exposed administrative interfaces
- Credential exposure in public sources
03
Exploitation
We attempt the exploit rather than reporting theoretical risk. Testing is deliberately controlled: we confirm access, capture evidence and stop short of anything that would disrupt a production service.
- Controlled exploitation of identified weaknesses
- Authentication and authorisation bypass testing
- Injection, configuration and logic flaws
- Evidence captured at each successful step
04
Post Exploitation and Escalation
A single foothold rarely matters on its own. What matters is what it reaches. We establish whether access can be escalated, whether we can move between systems, and whether we can reach the data the business would care about losing.
- Privilege escalation attempts
- Lateral movement between systems and segments
- Reachability of sensitive data stores
- Detection testing, whether anyone noticed
05
Reporting and Debrief
You receive an attack narrative that explains how we got in and why it worked, alongside a prioritised remediation list. We walk your technical team through it, and retest once fixes are in.
- Executive summary written for a board
- Technical narrative with reproducible steps
- Risk rated remediation priorities
- Debrief session and retest after remediation
What You Receive
- Executive summary written for a non technical audience
- Technical findings with reproducible steps and evidence
- Risk rated remediation priorities
- Debrief session with your technical team
- Retest report confirming closure
Indicative Timeline
A focused external test usually runs one to two weeks including reporting. Scope drives the duration far more than organisation size does, and retesting is scheduled separately once you have had time to remediate.
- Scoping and authorisation: two to three days
- Active testing: three to eight working days
- Reporting and debrief: three to five days
- Retest: scheduled after remediation
Types of Test
Scope is chosen against the threat you are actually worried about rather than sold as a fixed package.
External Network
Testing from the internet against your public facing infrastructure, the way an unauthenticated attacker would begin.
Internal Network
Testing from inside the network, simulating a compromised workstation or a contractor with a temporary login.
Web Application
Application logic, authentication, authorisation and injection testing against your own web systems.
Wireless
Testing of wireless network segregation, authentication and guest network isolation.
Social Engineering
Scoped phishing and pretext testing against staff, run only with explicit written authorisation.
Retest
Verification that remediated findings are actually closed, rather than accepted on the basis of an action plan.
Frequently Asked Questions
Is it safe to test against production?
Testing is controlled and we agree in advance how far exploitation may go. Where a system is fragile or business critical, we test a mirror of it or restrict to non disruptive techniques. Named contacts on both sides mean anything unexpected is stopped immediately.
What do you need from us before starting?
A signed scope and rules of engagement, confirmation that you own or are authorised to test the systems listed, written consent from any third party host, and emergency contacts. For internal or application testing we also need appropriate access.
How is this different from a vulnerability scan?
A scan lists what might be wrong. A penetration test establishes what is actually exploitable and what it leads to. Scans are cheap and should run regularly. Tests are deeper, cost more, and answer whether the weaknesses genuinely matter.
Will the report be usable by our IT team?
Yes. Findings include reproducible steps and evidence rather than a scanner reference number, so your team can confirm the issue and verify the fix themselves.
How often should we test?
Annually is the common baseline, plus after any significant change to the external footprint or a major application release. Regulated environments and organisations handling large volumes of personal information often test more frequently.
Do you retest after we fix things?
Yes. Retesting is quoted separately so you can remediate at your own pace rather than paying for a window you are not ready to use.
Related Services
This sits inside our Cyber Security Assessments practice. Related work: ICT Audit for the control and governance view of the same environment, and Managed ICT Services where you want the remediation carried out rather than only reported.
