Penetration testing: what it is, how it works and when to do it

A penetration test (or pentest) is a simulated, authorised cyberattack on an application, an API, a mobile app or a network, carried out by specialists to find out which vulnerabilities an attacker could really exploit, and with what consequences. It ends with a report setting out the weaknesses found, how serious they are and how to fix them, followed by a retest to verify the fixes.

Why do it

Attacks are on the rise, and Italy is among the hardest-hit countries. According to the Clusit Report 2026 (Clusit is the Italian Association for Information Security), known serious incidents in 2025 numbered 5,265 worldwide (up 49% on the previous year) and 507 in Italy (up 42%): roughly one in ten involved Italy. A penetration test does not make a system invulnerable, but it means weaknesses are found before the attacker finds them, when fixing them costs less.

Vulnerability assessment or penetration test?

	Vulnerability assessment	Penetration test
Goal	Find and rank known vulnerabilities	Show what can actually be achieved
Method	Largely automated, with manual verification	Mainly manual, led by a tester
Depth	Broad, across the whole scope	Deep, on the most relevant attack paths
Output	Prioritised list of vulnerabilities	Proof of exploitation, real impact, attack chains
When	Often, even continuously	Before major releases and periodically

It often makes sense to start with a vulnerability assessment to get a broad picture, then go deeper with a penetration test on the most exposed or most critical systems.

Types of penetration test

By how much the tester knows:

• Black box: the tester starts from scratch, like an outside attacker.
• Grey box: the tester has test accounts with different roles and some information about the architecture. It is the most widely used compromise, because it shows what a legitimate user can do beyond their permissions.
• White box: the tester also has access to the code and documentation. It is the most thorough.

By target:

• Web applications and APIs: authentication, session management, access control, injection, business logic.
• Mobile apps for iOS and Android: on-device data storage, communications, code protections.
• External and internal networks: exposed services, configurations, lateral movement.
• AI systems: prompt injection, data leakage, abuse of agent tools. We cover this in our guide to AI agent security.

How it works: the phases

1. Scope and authorisation. The scope is set down in writing: what will be tested, in which time windows, with which accounts and which techniques are excluded. Without written authorisation, testing does not start.
2. Information gathering. The systems, technologies, functions and roles involved are mapped out.
3. Vulnerability analysis. Scanners and manual checks identify the weak points.
4. Controlled exploitation. The tester tries to exploit the vulnerabilities and chain them together, stopping once the impact has been demonstrated, without causing damage.
5. Report. Every finding is documented with its severity, evidence and recommended fix.
6. Remediation and retest. After the fixes, the tester checks that the vulnerabilities really have been closed.

Public, recognised guides serve as the methodological reference: the OWASP Web Security Testing Guide for web applications, the OWASP MASVS and MASTG standards for mobile apps, and NIST SP 800-115 for the overall approach to testing.

What a good report must contain

• An executive summary, free of jargon: what was tested, what the company is at risk of and what to do first.
• For each vulnerability: description, severity (usually calculated with CVSS, now at version 4.0), evidence, steps to reproduce, impact and recommended fix.
• Priorities: what to fix immediately, what to fix in the next release, what to monitor.
• The outcome of the retest after the fixes.

A report that simply lists a scanner’s output is not a penetration test.

When to do a penetration test

• Before going live with a new application or with a feature that handles sensitive data or payments.
• After a significant change: a new architecture, a new authentication system, an AI integration.
• Periodically on internet-facing systems, at least once a year.
• When required by customers, partners, insurers or the regulations in your industry.
• After an incident, to find out whether other routes are still open.

How to prepare

1. Draw up a list of the systems in scope: domains, APIs, apps, environments.
2. Set up a test environment as close as possible to production, and test accounts for every role.
3. Check your backups and notify your hosting or cloud provider, if the contract requires it.
4. Appoint a contact person who can be reached during the test.
5. Set aside time for the fixes and for the retest: that is where the value of a pentest lies.

The most common mistakes

• Calling an automated scan a penetration test.
• Testing too narrow a scope, leaving out precisely the APIs or the admin panel.
• Skipping the retest after the fixes.
• Receiving a report that nobody in the company knows how to turn into concrete actions.

In our work, security starts with the code: in the systems we develop we use, for example, separate credentials for each device and signed firmware, as in the box that prints kitchen tickets. If you want to know how exposed one of your systems is, write to us: we agree on the scope and rules together before we start.