Offensive Security · Penetration Testing

Penetration testing: we prove the real impact, not just list the flaws.

Controlled exploitation of vulnerabilities to show what an attacker could actually do. Recognised methodologies (OWASP, PTES, NIST SP 800-115), CVSS severity, PoC and evidence, prioritised remediation and a retest after the fixes.

Controlled exploitation (not just scanning): we prove the impact, not just the existence of a flaw.
Black-box, grey-box or white-box across web/API, network, cloud and identity.
Report with CVSS, PoC, remediation and retest, readable by your client's CISO.

Request a penetration test See a sample report

When you need a penetration test

Quick self-qualification: do you recognise yourself in one of these?

An enterprise deal is stuck

A buyer sent you a security questionnaire or requires an independent pentest to sign the contract.

Go to path

Evidence for ISO 27001 / SOC 2

You need an independent test as evidence for the certification audit or the annual surveillance.

See ISO 27001

You shipped something new

New application, new API, cloud migration or major refactor: you want to know what's exposed before someone else finds out.

Talk to us

What a penetration test is (and isn't)

A penetration test is a controlled exploitation of vulnerabilities to demonstrate the real impact of a flaw, not just its existence. A human tester chains weaknesses, escalates privileges and reaches an objective, exactly like an attacker would, but under agreed rules of engagement.

It isn't a vulnerability assessment: a VA identifies and rates vulnerabilities (scanning + verification) without exploiting them. It isn't a red team: a red team simulates a real adversary against objectives and in stealth, also testing detection and response. If you're not sure what you need, write to us and we'll work it out together, honestly.

VA, penetration testing and red team are three different things. The pentest is usually what enterprise clients, ISO 27001 and SOC 2 ask for.

What we test and with which approach

What (scope): web applications and APIs, external and internal network, cloud (configuration review), identity and Active Directory, and, on request, mobile components or social engineering scenarios. We define the scope together during scoping.

How (approach): black-box (no prior information), grey-box (partial credentials or access, the most realistic scenario for most SaaS), white-box (full access to code and architecture, maximum coverage). We choose based on what you really want to uncover and the budget.

What you get: the report

Executive summary readable by non-technical stakeholders: what we found, how serious it is, what to do.
Technical findings with severity scored in CVSS (v3.1 / v4.0), not 'gut-feel' ratings.
Proof of Concept and evidence demonstrating the real impact of each exploitable finding.
Technique mapping to MITRE ATT&CK where useful to contextualise the attack.
Concrete remediation guidance prioritised by risk, not a generic copy-paste.
Retest after the fixes: we verify the corrections hold and close the loop.
A test letter/attestation you can share with clients and auditors (also via Trust Center).

How it works, step by step

A transparent process with agreed rules of engagement. Test execution is led by the human tester; AI helps with the repetitive part (triage, first draft), but every finding is verified manually.

1
Scoping & rules of engagement
We define perimeter, objectives, time windows, approach and written authorisation.
2
Reconnaissance & mapping
Information gathering, enumeration of the attack surface and exposed services.
3
Vulnerability identification
Targeted scanning and manual analysis to find the real weak points.
4
Controlled exploitation
Exploitation within the rules, chaining of flaws, escalation toward the objective.
5
Reporting
Findings with CVSS, PoC, evidence and prioritised remediation; executive summary included.
6
Retest
After the fixes we re-verify the findings and confirm closure.

Stack & methodologies

We work to recognised reference methodologies. OWASP: Top 10, WSTG (Web Security Testing Guide), ASVS for web apps and MASTG for mobile; PTES (Penetration Testing Execution Standard); NIST SP 800-115; OSSTMM. We map techniques to MITRE ATT&CK where it helps to contextualise.

The severity of every finding is scored with CVSS (v3.1 / v4.0): a shared, defensible and verifiable scale, not a subjective judgement. That's what makes the report hold up in front of a technical buyer.

Model and timing

1
Project model : 'from' price + range
A pentest is a project with a defined perimeter. The price depends on scope and approach: we pin it down after scoping. See the pricing page.
2
Execution : typically 1-2 weeks of testing
Varies with the breadth of scope and the depth required. Defined during scoping, no sight-unseen promises.
3
Retest included : after the fixes
We re-verify the corrected findings within an agreed window, so the final report reflects the real state.

If you need recurring tests, the pentest fits into the continuous-security retainer at a defined cadence.

No test 'guarantees' you're secure: a pentest photographs your posture within its scope and at the time of the test. Be wary of anyone promising absolutes: security is measured in risk reduction.

Frequently asked

What's the difference between a penetration test and a vulnerability assessment?

A vulnerability assessment identifies and rates vulnerabilities (scanning + manual verification) with CVSS severity, without exploiting them. A penetration test goes further: it controllably exploits flaws to demonstrate their real impact. Often you start from a VA and dig deeper with a pentest where it matters.

And red team? Is it the same thing?

No. A red team simulates a real adversary against objectives (not a predefined scope), often in stealth, and tests detection and response too. It's advanced: it makes sense when you already have a mature posture. For most enterprise clients and for ISO/SOC 2, what you need is a pentest.

Black-box, grey-box or white-box: which do I pick?

Black-box simulates an external attacker with no information; grey-box starts from partial credentials or access and is the most realistic scenario for many SaaS; white-box gives access to code and architecture for maximum coverage. We advise based on what you want to uncover and the budget.

Do I need a pentest for ISO 27001 or SOC 2?

It's very common evidence for both the certification audit and the annual surveillance and for client security questionnaires. It isn't a formal requirement in itself, but it's the most credible way to show you genuinely test your technical controls.

What do I get at the end?

A report with an executive summary, findings with CVSS severity, PoC and evidence, prioritised remediation and a retest after the fixes. Plus a test letter/attestation you can share with clients and auditors, including via Trust Center.

Do you guarantee no vulnerability will be left?

No, and be wary of anyone who promises it. A pentest photographs your posture within scope and at the time of the test: it reduces risk and prioritises fixes, but 'zero risk' doesn't exist. That's why testing over time matters.

Go deeper

Audit & Pentest (hub)

Our testing line: VA, penetration testing and red team explained together, with the delivery model.

Go to the hub

Sample report

An anonymised report: executive summary, findings with CVSS, evidence and remediation. Decide before you decide.

See the report

Vulnerability Assessment

When you just need the broad, recurring picture of vulnerabilities, without active exploitation.

Learn more

Want a pentest that holds up in front of a technical buyer?

Tell us the scope and objectives: we'll advise the right approach, honest timelines and a 'from' price.

Request a penetration test