We test the way attackers actually do.

Penetration testing is an authorised simulated attack on your systems, carried out to find and prove the weaknesses a real attacker would use. It differs from a scan in that a human operator chains findings together and demonstrates actual impact: data read, an account taken over, money moved. The output is a report of what was proven, not a list of what might be wrong.

A vulnerability assessment enumerates known weaknesses, usually with automated tooling, and reports them as a list. A penetration test attempts to exploit them, chains them together, and demonstrates real impact. The first tells you what might be wrong; the second tells you what an attacker can actually do. Most products sold as penetration tests in this market are vulnerability assessments with a different cover page. The tell is a report with hundreds of findings and no working proof of concept.

By target: web application, API, mobile application, cloud, internal and external network, source code review, and IoT or embedded. By method: black box with no information, grey box with credentials and documentation, and white box with source access. Most commercial engagements are grey box, because starting an authenticated tester outside the login page spends your budget on reconnaissance rather than on findings.

External testing starts from the internet and asks what an attacker reaches without any access. Internal testing starts from inside the network, usually from a standard user account, and asks how far one compromised workstation reaches. Most organisations need both: the external test defines the perimeter, and the internal test answers what happens after a phishing email succeeds, which it eventually will.

Cost follows scope, not a price list: the number of applications, roles and endpoints, whether internal network testing is included, and whether source code is in scope. A fixed quote is issued after a short scoping call, with no hourly billing and no change orders mid-engagement unless you change the scope.

Five to fifteen working days for a typical web application and API engagement, plus two to three days for reporting. Network engagements scale with host count; mobile adds roughly five days per platform. Add one to two weeks of lead time from signed scope to start, and allow for a retest two to four weeks after delivery once fixes are in.

Annually as a baseline, which is what most frameworks expect, plus after significant change: new authentication, new roles, a new tenancy model, a payments integration or a major infrastructure migration. Teams deploying continuously typically run one full annual engagement and shorter delta tests after major releases.

Three documents. A technical report for your engineers with every finding, its severity, the full request and response, reproduction steps and a working proof of concept. An auditor-facing summary with scope, methodology, dates and outcomes. A redacted attestation letter with no exploitation detail, written to be shared with customers under NDA. Findings are mapped to whichever framework you agreed at scoping.

You get the report and a readout session with the people who did the testing, then you remediate, then every finding is retested in a clean session and closed only when re-exploitation fails. A signed attestation follows, recording what was raised, what was fixed and what was verified. That attestation is usually the document your auditor or enterprise buyer actually wants.

SOC 2 does not name penetration testing, but auditors ask for it and the monitoring criteria are hard to evidence without it. Testing supports CC4.1 on control monitoring, CC7.1 on vulnerability detection and CC7.2 on anomaly monitoring. For a Type II, run it before the observation window opens so findings are remediated and re-verified inside the period rather than sitting open in the auditor's sample.

Not by name. ISO 27001 requires that technical vulnerabilities be identified and managed (Annex A.8.8), that security testing happen during development and acceptance (A.8.29), and that control effectiveness be evaluated (Clause 9.1). Certification bodies consistently accept independent penetration testing as evidence for all three, and increasingly expect it for any organisation with a significant internet-facing estate.

Yes. PCI DSS requirement 11.4 mandates internal and external penetration testing at least annually and after any significant change, performed by a qualified tester who is organisationally independent of the system being tested. Where segmentation is used to reduce scope, that segmentation must also be tested, every six months for service providers and annually for merchants.

Ask four questions and insist on evidence for each. Who performs the test. Named, certified testers you are told about before you sign, not an anonymous pool. What they have found before. A public research record, Hall of Fame acknowledgements or disclosed advisories. What you receive. Ask for a redacted sample report before signing; it tells you more than any sales call. Whether retesting is included. If fixes are not re-verified, the engagement is incomplete by design.

Then check one more thing: whether the firm holds a security certification of its own. You are about to hand someone a list of live vulnerabilities in your platform.

Named, certified testers from our team, agreed with you during scoping and held to contractually. Not an anonymous pool, and not juniors working under a senior's byline. You can ask for the CVs and certifications of everyone assigned before you sign, and delivery is reviewed by our Principal Consultant. The certifications held across the team are listed on the credentials page.