Penetration testing
Testing your defences with an attacker’s methods.
We attack your applications, APIs and infrastructure the way an attacker would, but with authorisation, within an agreed scope and time windows, and with the aim of closing every flaw we find.
- Written authorisation
- Agreed windows
- Retest included
For decision-makers
What a penetration test is, in plain language.
It is a controlled, authorised attack, carried out to find out what a real attacker could do, before they try.
- It shows the real risk. Knowing a flaw exists is not enough: the test shows how far it leads.
- It tests the whole. Application, server, configuration and integrations, as they actually run.
- It follows rules. Scope, windows, contacts and stop conditions agreed in writing.
- It ends with the flaws closed. The retest confirms that the fixes worked.
Applications and APIs
Portals, back offices and REST or GraphQL APIs.
Infrastructure
External perimeter, internal network and directory.
Mobile applications
Android and iOS apps and the APIs they depend on.
With a retest
Confirmation that every flaw is closed.
What we test
Three kinds of test, one methodology.
-
Web applications and APIs
We follow the OWASP Web Security Testing Guide (WSTG) for web applications and the OWASP API Security Top 10 for APIs.
- Authentication, sessions and account recovery
- Permissions between users and roles
- Injection, validation and file uploads
- Business logic and usage limits
-
Infrastructure
We assess what is exposed to the internet and, with network access, what an attacker could do from the inside.
- Exposed services and vulnerable versions
- Remote access and VPN
- Active Directory and Microsoft Entra ID
- Configuration, passwords and segmentation
-
Mobile applications
We follow the OWASP Mobile Application Security Testing Guide (MASTG), on Android and iOS.
- Data stored on the device
- Communications and certificates
- Protection of the app’s code
- Back-end APIs
Approaches
How much we know before we start.
The approach sets the information you give us at the outset. Grey box is the one we recommend in most cases.
| Approach | What we know | When to use it |
|---|---|---|
| Black box | Only the system’s address, like an outside attacker. | To measure exposure to someone with no access at all. |
| Grey box | Test accounts with the usual roles and basic documentation. | Recommended: covers more in less time and tests permissions between users. |
| White box | Access to the code and the architecture, together with a code audit. | For critical systems, where the most complete coverage is wanted. |
How a test runs
From scope to retest, always in touch.
-
Scope and authorisation
Systems, addresses, test accounts, windows and contacts agreed and authorised in writing.
-
Reconnaissance
A survey of what is exposed: services, versions, technologies and entry points.
-
Testing
Automated and manual tests, guided by OWASP methodologies and by what reconnaissance revealed.
-
Confirmation
Every flaw is confirmed without causing harm; a critical flaw is reported the same day.
-
Report
Findings by severity, with evidence, the attack narrative and the proposed fixes.
-
Retest
After the fixes, we confirm that every flaw is closed.
Rules of engagement
Attacking carefully is a skill too.
The rules are written down before the first test and protect your service, your data and the people who use them.
- Written authorisation from the system owner and, where its terms require it, from the hosting provider.
- A closed scope: only the agreed addresses, applications and accounts.
- Agreed windows for the most intrusive tests, preferably in test environments.
- An emergency contact on both sides throughout the work.
- Stop conditions: we stop immediately if asked or if the service is affected.
- No real data at risk: we do not copy personal data beyond the minimum needed to prove a flaw.
- Clean-up at the end: test accounts, files and changes are removed and checked.
Authorisation
Nothing is tested without written authorisation.
Windows
Intrusive tests run at agreed times.
Direct contact
A person available throughout the work.
Confidentiality
Findings and evidence handled in the EU.
Tools
Open tools, analysis done by people.
We use recognised open-source tools to cover the essentials quickly. What sets a test apart is the manual work that follows.
- Tools find candidates; people confirm them, chain flaws together and assess the real impact.
- Business logic and permissions between users can only be tested by hand.
- Every finding is reproduced before it goes into the report, with no lists of false positives.
ZAP
Web application and API testing.
Nmap
Discovery of hosts and services.
Nuclei
Known flaws and insecure configurations.
sqlmap
Confirmation of SQL injection.
MobSF
Mobile application analysis.
AI with human review
Help with the analysis, always confirmed by a person.
What you receive
A report that tells how the attack would happen.
For every important flaw, we show an attacker’s path, step by step, and how to close it. See what a full report looks like.
- An executive summary for management, with the level of risk and the priorities.
- An attack narrative for critical flaws: from first access to impact.
- A technical report with evidence, severity measured with CVSS 4.0 and proposed fixes.
- Fixes made by us or by your team or supplier, as you prefer.
- A retest and final report with the status of every finding.
Frequently asked questions
About penetration testing.
Can the tests bring the service down?
We plan everything so that it does not happen. The most intrusive tests run in test environments or in agreed windows, there is always a direct contact, and we stop immediately if the service is affected.
Do you test in production?
When needed, yes, with extra care: less intrusive tests, windows outside peak hours and accounts created for the purpose. Whenever there is a test environment identical to production, we prefer to use it.
Do we have to tell our hosting provider?
It depends on your provider’s terms. Some require notice or prior authorisation for security tests. We check this with you while defining the scope.
What happens if you find a critical flaw?
We tell you immediately, the same day, without waiting for the report. We agree the urgent measures with you and, if you wish, help apply them.
How often should we run penetration tests?
At least once a year and after every significant change, such as a new release, a new integration or a move to new hosting. The annual subscription covers this schedule.
Want to know how far an attacker would get?
Tell us which systems you want tested and we will propose a fixed scope, approach and price.