What is a penetration test?
A penetration test is a manual, goal-driven attack on your system by engineers who behave like a real adversary: reach customer data, take over an account, get from the public API to the internal network. Unlike a scanner, a pentester chains small findings and business-logic flaws into a working attack path and hands you proof of what is actually exploitable, ranked by real impact. The output is not a list of CVE numbers but a set of verified, reproducible findings with a fix for your stack.
The threat is not theoretical: according to the Verizon Data Breach Investigations Report, exploitation of vulnerabilities as the initial way into a breach grew roughly 180% year on year (Verizon, 2024). A pentest finds those entry points before someone else does.
Pentest vs vulnerability scan: which do you need?
The short answer: both, at different cadences. A vulnerability scan is cheap, automated and repeatable, so it belongs in the monthly routine; a penetration test is manual and deep, so it belongs before launches, after major releases and once a year. PCI DSS v4.0, for example, requires quarterly vulnerability scans and at least an annual penetration test (PCI SSC, 2024).
| Criterion | Vulnerability scan | Penetration test |
|---|---|---|
| Method | Automated tools matching known signatures and CVEs | Manual work by engineers, tools as one input |
| Depth | Wide but shallow; no exploitation | Chained exploitation, business logic, access control |
| False positives | Common; need manual triage | Every finding is proven with a reproduction |
| Output | Prioritised list of known weaknesses | Attack paths, impact, CVSS score, fix per finding |
| Cadence | Monthly or on every release | Annually and after major changes |
| Effort and duration | Hours to a day | One to four weeks |
What do we test?
We test the assets an attacker can actually reach: web applications and APIs, mobile apps, cloud accounts, the external perimeter and the internal network. For each one we follow the matching OWASP standard, and we can work black, grey or white box depending on whether you want a simulation of a blind attacker or maximum depth for the budget. Broken access control is the finding we meet most often — OWASP put it at number one in its Top 10 and found some form of it in 94% of the applications it analysed (OWASP, 2021).
- Web applications and APIs — OWASP Top 10 and OWASP ASVS: injection, broken authentication and access control, IDOR, SSRF, business-logic abuse, REST/GraphQL/WebSocket APIs, SSO/OAuth/OIDC flows.
- Mobile apps (iOS, Android) — OWASP MASVS: local storage, transport security, certificate pinning, reverse engineering, API misuse.
- Cloud infrastructure — AWS, GCP, Azure: IAM and privilege escalation, exposed storage, misconfigured Kubernetes, secrets in CI/CD, network segmentation.
- External and internal network — perimeter, VPN, exposed services, Active Directory, lateral movement.
- Grey/white box — with credentials, architecture docs or source code when you want depth instead of a simulation of a blind attacker.
How does a penetration test run?
A pentest runs in seven phases over one to four weeks: reconnaissance, threat modelling, discovery (automated and manual), exploitation, post-exploitation, reporting and retest. We follow PTES and the OWASP Testing Guide, score severity with CVSS v4.0 (FIRST, 2023) and then adjust the rating to your business context — a "medium" on the payment flow is not a "medium". Critical findings are reported the same day they are found, not at the end.
Tools are the boring part — Burp Suite, Nuclei, nmap, sqlmap, ZAP, cloud-native scanners, our own scripts. What matters is the engineer who reads the response and knows what the framework does with it: our testers build systems in Python, PHP, Node.js and Vue/React every day. Speed matters too: Mandiant reports a global median dwell time of about 10 days between intrusion and detection (Mandiant M-Trends, 2024), which is roughly how long a real attacker has to work with the same finding.
What do you get?
You get two documents and two meetings: an executive summary for management, a technical report for engineers, a debrief call and a retest. Every finding includes steps to reproduce, evidence, a CVSS score, affected assets and a concrete fix for your stack, so the report can be turned into tickets the same day. Given that the average cost of a data breach reached USD 4.88 million (IBM, 2024), the point of the report is not the PDF but the fixed system behind it.
- Executive summary: risk level, top findings, what to fix first.
- Technical report: every finding with reproduction, evidence, CVSS score, affected assets and a fix.
- Debrief call with your engineers; critical issues reported the same day they are found.
- Free retest within 60 days and a letter of attestation for customers, partners and auditors.
How do we keep testing safe for production?
Testing on a live system is safe when it is planned in writing before the first packet is sent. We agree scope and authorisation, test windows, rate limits, stop conditions and emergency contacts on both sides. No destructive actions and no social engineering unless explicitly ordered; destructive checks run against staging or with separate approval. Findings travel only over agreed encrypted channels, test artefacts are deleted at the end of the engagement and deletion is confirmed in writing. An NDA is signed before scoping.
Request a scoping call — we reply within one business day with questions and an estimate. Teams that ship often should pair pentests with DevSecOps in the pipeline.