Penetration testing (a pen test) is a controlled attack on your systems by a specialist who uses a real attacker's techniques, within a scope and authorisation agreed in writing. Its purpose is to show which weaknesses can actually be exploited, how far an attacker could get by chaining them, and what to fix first.
A vulnerability scan tells you a lock might be missing; a penetration test shows whether the door actually opens and what lies behind it. Below we cover the types of penetration testing, how the process works step by step, what drives the cost and how to read the report.
What is penetration testing for, and when do organisations need it?
Most businesses arrive at penetration testing because something external forces the question. A large customer sends a supplier security questionnaire. An auditor asks when the systems were last tested. A new customer portal is about to go live. Someone notices an admin panel that is reachable from the internet. At that point the IT team usually has a firewall, endpoint protection and servers that are "probably up to date", but no picture of the estate as an attacker would see it.
The underlying problem is that internal teams see systems the way they built them. A forgotten test account, a port opened for a supplier and never closed, an IP camera still on its default password, a plug-in stuck on an old version: all of these become invisible in day-to-day work. A penetration test brings those blind spots into view from the outside, with evidence.
What leaving the gaps open really costs
Attackers largely get in by two routes: tricking people and exploiting known weaknesses. Penetration testing targets the second route directly; the first depends on staff knowing how to spot phishing emails.
According to ENISA, based on 4,875 incidents analysed in Europe between July 2024 and June 2025, phishing was the leading initial intrusion vector at about 60%, while exploitation of vulnerabilities remained a prevalent route in at 21.3%. (ENISA Threat Landscape 2025)
The bill for a breach is substantial. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a data breach at a record $4.99 million, up 12% on the previous year. That figure is weighted towards large enterprises, but for a smaller business the proportional impact is often harder to absorb: stalled orders, lost data and damaged trust all land on the same small team. If personal data is involved, the 72-hour KVKK breach notification process is added on top.
Nor is your attack surface limited to your own servers. In the Verizon 2026 Data Breach Investigations Report, breaches involving a third party rose 60% in a year to reach 48% of all breaches. The VPN account opened for a supplier, the API key issued for an integration and the website managed by an outside agency are all entry points that belong in the test scope.
Penetration testing vs vulnerability scanning
The two are often confused, which leads to proposals being compared like for like when they are not. In short:
| Vulnerability scan | Penetration test | |
|---|---|---|
| Method | Automated tools look for known weaknesses | A specialist manually verifies and chains attack attempts |
| Output | A list of known issues with CVSS scores | Exploitable findings with evidence and business impact |
| False positives | Relatively high; needs triage | Low; every finding is verified |
| Logic flaws | Not detected | Authorisation bypasses and workflow flaws are tested |
| Frequency | Continuous or monthly | Annually and after major changes |
They are not alternatives. Regular vulnerability scanning keeps patch management discipline alive; a penetration test reveals the logic flaws scanners miss and the real risk created when several small issues combine.
Types of penetration test
By level of knowledge: black box, grey box, white box
- Black box: the tester receives only a domain name or IP range, simulating what an outside attacker can see.
- Grey box: the tester receives a normal user account. For web applications this is usually the most productive approach, because it answers questions such as "can a logged-in customer see someone else's orders?"
- White box: architecture, configuration and, if you wish, source code are shared. It is the deepest option, and the one that needs the most preparation.
By target
- External network: internet-facing servers, VPN, email and remote access services.
- Internal network: assumes an employee's laptop has been compromised and measures how far an attacker can move inside the network.
- Web application and API: the OWASP Top 10 categories, including SQL injection, cross-site scripting, broken access control and weak session handling.
- Wireless: whether the guest network offers a path into the corporate network.
- IoT and OT: cameras, card access control and other access control devices, PLCs and SCADA systems, tested under a separate plan so production is never put at risk. We cover this in detail in our article on OT security for SCADA environments.
The penetration testing process, step by step
The value of a pen test depends heavily on how well the engagement is set up:
- Scope and written authorisation. Systems, IP ranges, time windows and prohibited actions (for example anything that could cause an outage) are agreed in writing, along with a confidentiality and authorisation agreement. Systems hosted by third parties need that party's consent too.
- Reconnaissance. Open ports, service versions, subdomains, leaked email addresses and everything else visible from outside are mapped.
- Vulnerability discovery. Automated scans and manual review produce a list of candidate weaknesses.
- Verification and exploitation. Each weakness is verified in a controlled way without interrupting service; where possible, findings are chained to show the full impact path.
- Reporting. Findings are written up in order of severity, with evidence and a remediation step.
- Remediation and retest. Your team applies the fixes; a retest confirms the critical findings are closed.
Reading the report properly
A good report is written for two audiences. The executive summary answers, without jargon, "what are the three biggest risks, what is the business impact and by when must they be fixed?" The technical section gives, for each finding, the affected system, steps to reproduce, evidence (screenshots, request and response samples), a severity rating such as CVSS and a concrete fix. A report that simply pastes tool output and says "critical: 3, high: 12" without telling you what to fix first is only half the job. Once the report arrives, give every finding an owner and a date; otherwise it will sit in a folder until the next test.
The findings we see most often
Findings in smaller organisations are rarely exotic. The usual suspects are a VPN or remote desktop service that is behind on patches, a camera or network device left on its default password, administrator accounts without multi-factor authentication or with weak passwords (see our guide to business password security), web applications where a logged-in user can change a number in the address bar and see another customer's record, and production devices sitting on the same network as office laptops. The good news is that most of these can be closed within a few weeks once they are prioritised properly.
How often should you test?
Common practice is to test critical systems at least once a year and after every major change: a new customer portal, exposing the ERP to the internet, a move to the cloud, a new integration or a change in network design. In between, run continuous vulnerability scanning and patch tracking. For systems that process personal data, test results can also serve as evidence of technical measures under data protection compliance work; KVKK, Türkiye's Personal Data Protection Law No. 6698, requires data controllers to take technical measures that ensure an appropriate level of security. To plan the routine controls that should sit between tests, see our SME cyber security checklist.
Customer and audit requirements also set the pace: in an organisation working to ISO 27001, regular penetration tests and a record of how findings were closed are among the strongest evidence of technical vulnerability management.
How we run penetration tests at Digital Bridge
As part of our cyber security consultancy, we run penetration tests in four stages:
- Scope and authorisation: we agree with you, in writing, which systems will be tested, when and within what limits, and sign the confidentiality and authorisation agreement.
- Reconnaissance and scanning: we map the systems, open ports and known vulnerabilities visible from outside and inside. For web applications and APIs we use scenarios based on the OWASP Top 10 and published CVE records.
- Verification: we confirm whether each weakness is genuinely exploitable, in a controlled way and without interrupting service.
- Report and remediation plan: findings are reported by severity, each with a practical fix, and we can retest once remediation is done.
What sets us apart is that software and hardware are built by the same team. If a fix requires a code change, our custom web software developers can show exactly how to make it; if an integration is the weak point, we can design secure authentication on the API integration side with you. Because we develop our own IoT devices and industrial software, we can also test factory networks, PLCs and SCADA systems without putting production at risk. If your systems are about to move to the cloud, building the test into your cloud migration and infrastructure plan lets you close gaps before you migrate them.
If an outside firm develops your software, write the right to security testing, and who fixes any findings within what timeframe, into the contract from the start; we cover these clauses in our article on software contracts and source code ownership.
Next step
Before any test, draw up a short inventory: which services are exposed to the internet, who has access from outside, and where your most critical data lives. That list is the basis for drawing the scope correctly and spending the budget on the systems that matter. Then get in touch; we will define the scope with you and send a written proposal with clear stages and cost. Guides for what comes before and after a test are collected in our Cyber Security & Compliance guide.