Penetration Testing Services for UK Small and Medium Businesses

What a penetration test actually involves

A penetration test is not a scan. A tester works the way an attacker works: mapping what you expose, looking for the weak link, and chaining small issues together into something that matters. A password policy weakness on its own is a medium finding. The same weakness combined with an exposed remote desktop gateway and a service account with domain administrator rights is a full compromise, and that is the sort of chain only a human finds.

Everything is authorised in writing before we begin. Scope, timing, target systems, what is explicitly off-limits, and an emergency contact are all agreed in a rules of engagement document you sign. Testing without that document is a criminal offence under the Computer Misuse Act 1990, and no reputable firm will proceed without one.

• ✓Reconnaissance and attack surface mapping
• ✓Vulnerability identification and manual verification
• ✓Controlled exploitation to establish genuine impact
• ✓Privilege escalation and lateral movement where in scope
• ✓Evidence capture, then a clean tear-down of any test artefacts

Choosing the right type of test

Black box testing gives the tester nothing but a company name or a URL, mimicking an outside attacker with no inside knowledge. It is realistic but spends a lot of billable time rediscovering things you could simply have told us. Grey box gives the tester standard user credentials, which is usually the best value for money because it mirrors the most common real scenario: an attacker who has phished one employee. White box provides full documentation and source code, giving the deepest coverage per pound spent.

For most SMEs we recommend grey box against the web application and external perimeter, with an internal assumed-breach test if you hold sensitive data on a company network.

• ✓Black box — realistic outsider view, best for validating perimeter defences
• ✓Grey box — standard user credentials, best value and most realistic breach model
• ✓White box — full access and documentation, deepest coverage for critical apps
• ✓Assumed breach — starts from a compromised workstation to test internal containment

Web application and API testing

If you have built or commissioned a web application — a customer portal, a booking system, an online shop, an internal tool exposed to the internet — that application is usually the single highest-risk asset you own. It is reachable by anyone, it talks directly to your database, and it was probably built to a deadline.

We test against the OWASP Web Security Testing Guide: injection, broken access control, authentication and session flaws, insecure direct object references, server-side request forgery, and the business logic problems automated tools never catch — such as being able to change a price, view another customer's order, or skip a payment step by manipulating a request.

• ✓Broken access control and horizontal or vertical privilege escalation
• ✓Injection flaws including SQL, command and template injection
• ✓Authentication, password reset and session management weaknesses
• ✓Business logic flaws unique to how your application works
• ✓API authorisation, rate limiting and data exposure issues
• ✓File upload handling, SSRF and insecure deserialisation

The report is the product

You are not buying a test, you are buying a document you can act on and — often — send to a customer. Ours contains an executive summary in business language, a clear statement of what we achieved and how far we got, and a technical section where every finding carries evidence, reproduction steps, business impact and a specific fix.

We do not pad reports with informational findings to make them look thorough. If we found three things that matter, the report says so and explains them properly.