CREST accredited penetration testing

Find the weaknesses an attacker could exploit.

Understand how an attack could affect your business, give your team a clear order for fixes, and verify that those fixes work.

Scope a penetration test

What do you need to test?

Start with the environment or business process you want to test. Each service explains the scope, what to prepare and the evidence your team will receive.

Cloud testing

Can an exposed service or overly broad cloud role reach another account or workload? Test named environments within the provider’s rules.

Cloud environments

Web application testing

Can a customer see another account’s records, bypass a workflow or call an API directly? Choose the application or interface that holds the data.

Infrastructure testing

What can an outsider reach, and how far could an ordinary user move inside the network? Choose the starting position and systems you want examined.

Mobile application testing

What could someone recover from a phone or change in a request to the backend? Scope the iOS or Android build and the services it uses.

Mobile applications

Red teaming

Could the organisation detect and contain an attempt to reach a critical business system? Scope an objective-led exercise or an intelligence investigation.

Social engineering

Would a sensitive request or an unexpected visitor get past your checks? Test a business procedure, a physical site or both within an agreed scope.

Illustrative report extract

One customer can read another customer’s invoice.

A signed-in user changes the document ID in a request. The application returns an invoice belonging to another account.

See how API authorisation is tested.

What goes into the report

Finding: The application checked that the user was signed in, but did not check whether they owned the requested invoice.
Business impact: A customer could access another customer’s billing information. The report identifies the affected action and the evidence needed to reproduce it.
Fix and retest: Check account ownership on each request. Repeat the test with two accounts and verify that access to the other customer’s invoice is refused.

From agreed scope to verified fixes.

Agree the boundaries

Agree the named systems and accounts, authorised owner, testing window, excluded actions and escalation contact. Confirm permission for third-party infrastructure before it is tested. The existing rescheduling policy applies to the engagement.

Choose a starting point

We can start as an outsider with no account (black box), with an agreed user role (grey box), or with access to designs and source code (white box). For example, two customer accounts let us test whether one user can read the other’s invoices through the API.

See findings as testing progresses

See material findings as they are confirmed. The report records the affected asset, reproducible evidence, business impact and recommended fix. It distinguishes what was tested from what fell outside scope.

Verify remediation

For 12 months, Vambrace offers free re-tests of vulnerabilities identified in the original engagement. The re-test checks whether the original route is closed; changes to the application or wider estate may need separate testing.

Download the penetration testing guide (PDF) ↗