Cybersecurity & pentest
Test your security the way it could actually be attacked.
A penetration test does not produce a list of theoretical vulnerabilities. It tells you what an attacker would actually obtain on your perimeter, through which path, and what that would cost your business. Scope agreed with you, written authorisation, and a report your teams can genuinely act on.
When does a penetration test make sense?
A pentest is useful when there is a decision to make, not just a box to tick.
You are putting an internet-facing application into production and you want to know what it lets through before your users find out.
A client, an insurer or a tender requires evidence of a test carried out by a third party.
Your application has changed a lot since it was designed and nobody has reviewed the exposed surface since.
You have opened an API to partners and you do not know what it exposes beyond the intended use.
You have inherited an infrastructure, a codebase or a previous supplier and you lack visibility.
You want to know how far someone already inside your premises or connected to your internal network could go.
What we test
Each type of test answers a different question. The scope is defined before the engagement, not discovered during it.
Web applications
- Authentication, session handling, password reset
- Access control: reaching another account's data, acting with a role you do not hold
- Injection, input handling, deserialisation
- Business logic: workflow bypass, tampering with amounts or statuses
- Exposed configuration: headers, cookies, CORS, overly talkative error messages
APIs and integrations
- Machine-to-machine tokens: scope, lifetime, revocation
- Per-resource authorisation and exposure of unintended objects
- Undocumented endpoints and old versions left active
- Rate limiting, abuse and identifier enumeration
- System-to-system exchanges: webhooks, message queues, partner connectors
External infrastructure
- Mapping of the genuinely exposed surface
- Internet-reachable services that should not be
- TLS configuration, missing patches, exposed versions
- Forgotten assets: test environments, old servers, reachable backups
Internal infrastructure
- What a workstation simply plugged into the internal network obtains
- Escalation paths towards high-privilege accounts
- Network segmentation: what is reachable, and from where
- Shares, service accounts and secrets stored in clear text
On-site testing
- Segmentation from a network socket or a guest workstation
- Wi-Fi access and effective network separation
- What an external visitor present in your premises can reach
- Scenarios agreed in advance, with no testing of your staff without prior written consent
Red Team engagement
- Separate contract, agreed scenario, goal set in advance
- Assesses your detection and response, not only your vulnerabilities
- Assumes existing maturity: without the more conventional tests first, it adds nothing
- We will tell you plainly if this is not what you need right now
What you are actually buying, by type of test
These words mean different things from one supplier to the next. Here is how we use them, so you know what is included before comparing two quotes.
| Type | Goal | Depth | Human involvement | Attack scenario | Deliverable |
|---|---|---|---|---|---|
| Vulnerability scan | Spot known weaknesses | Surface level, no exploitation | Automated tool, light review | None | A list of findings to triage |
| Audit | Check compliance against a framework | Configuration, code, procedures | Document review and interviews | None | Gaps against the framework |
| Penetration test | Find out what an attacker would obtain | Real exploitation, through to business impact | Manual, guided by your business | Attack paths across a defined scope | Reproducible findings and a remediation plan |
| Red Team engagement | Assess detection and response | One target, stealth sought | Manual, over a longer period | An end-to-end agreed scenario | An account of the intrusion and the blind spots |
These definitions are not a standard: other suppliers use the same words differently. Compare what is actually covered, not the label.
How an engagement runs
The framework is agreed before the first request. No test starts without explicit authorisation from the system owner.
- 01
Scoping
What must be tested and why: environments, applications, address ranges, test accounts, timing and load constraints.
- 02
Rules of engagement
Scope, permitted methods, testing windows, emergency contacts and stop conditions, written down and signed. That document governs the whole engagement.
- 03
Authorisation
Testing starts with the written consent of the system owner. If your hosting or managed-services provider must be notified, we verify that beforehand.
- 04
Reconnaissance
Mapping of the surface actually exposed. This step regularly surfaces assets nobody had in mind any more.
- 05
Testing
Manual exploitation guided by business context, tool-assisted but not automated. Any critical finding is reported to you immediately.
- 06
Reporting
Every finding with its reproduction path, its real impact and the expected fix. Prioritised by business risk, not by raw score.
- 07
Debrief and retest
A walkthrough with the technical teams and the decision-makers, then verification of the fixes on the points addressed.
We never test a system without written authorisation from its owner. If the scope includes resources hosted by a third party, that third party’s consent is verified before we start.
What you receive
A report is only worth something if it leads to fixes. We write for your developers and administrators, not to justify the engagement.
- 01
Technical report
Every finding with its reproduction path, the evidence, the severity and the expected fix.
- 02
Executive summary
What is at stake, in business terms, usable in a board meeting or in front of a client.
- 03
Prioritised remediation plan
What to fix first, what can wait, and what is an architectural decision rather than a patch.
- 04
Debrief with your teams
A direct conversation with developers and administrators, so the report does not end up filed and forgotten.
- 05
Retest of the fixes
Verification of the corrected items after your remediation pass, with the status of each finding updated.
- 06
Test attestation
The scope and period of the test, attested — useful for a client, an insurer or an auditor.
The environments we cover
Security is tested where the system lives, not on an architecture diagram.
Web applications and SaaS
Internal business applications, client portals, internet-facing platforms.
APIs and services
REST, GraphQL, internal services and integrations with your partners.
Cloud and hosting
Public cloud environments, dedicated hosting and hybrid setups.
Corporate networks
Directories, workstations, internal servers, segmentation and remote access.
After the test
A penetration test is only worth the fixes that follow. We can stop at the report, support your teams, or take remediation on ourselves.
Custom project
We take responsibility for the whole thing: analysis, design, development, integration, delivery and evolution.
Learn moreConsulting & team extension
Our consultants join your team to bring the skills you need: development, functional analysis, technical analysis, business analysis or architecture.
Learn moreIT partner
A lasting point of contact to maintain, evolve and connect the software and systems your business runs on.
Learn more
What security overlaps with
The topics that most often come up alongside or after a test.
Secure applications and infrastructure
You need to demonstrate a level of security, or you are unsure how exposed your applications really are.
Connect systems that don’t talk to each other
Your ERP, your CRM and your business tools each hold part of the truth, with no reliable exchange between them.
Modernise business software
The application still works but is becoming expensive to maintain, hard to change and dependent on a handful of people.
Frequently asked questions
Can a pentest break production?
The risk is never zero, which is why it is handled in the rules of engagement: excluded tests, testing windows, stop conditions. Where possible, we work on a representative pre-production environment. When the test has to happen in production, we adjust intensity and stay reachable throughout.
Black box, grey box or white box?
In black box we start with no information, like an external attacker. In grey box we hold user accounts, which is what makes it possible to test access control and business logic — the most useful mode in the majority of cases. In white box we also have the code and the diagrams, which gives the broadest coverage for the same amount of time.
How long does an engagement take?
It depends on the scope, and the scope has to be defined before a duration can be quoted. A single application with a handful of roles is not the same effort as a full information system. We price after scoping, based on what genuinely has to be covered.
Is an automated scan not enough?
A scan detects known weaknesses: outdated versions, default configurations, missing patches. That is useful, and often a legitimate first step. But a scanner does not understand your business: it will not notice that a user can read another client’s orders, skip a validation step or change an amount.
How often should we retest?
After every significant change to the exposed surface: a new application, a redesign, opening an API, changing hosting. Many organisations retest their external perimeter once a year, but a calendar rhythm does not replace a test triggered by an actual change.
Do you work with our teams or instead of them?
Both are possible. Some clients only want the report and fix things internally. Others ask us to support their developers through remediation, or to take it on entirely.
Let’s talk about your scope
One conversation is enough to determine which type of test fits your situation — and whether it is really what you need right now.