Penetration testing

See what a real attack on your systems would look like

We help you understand how your systems behave when facing real attack attempts, where the exploitable vulnerabilities are and what impact they could have on your organisation.

What is penetration testing

Penetration testing is a controlled simulation of a cyberattack on your systems.

More specifically, we try to see:

Major Changes

After major changes to applications or infrastructure

Public Systems

You have publicly exposed systems (websites, portals, APIs)

Regulatory Compliance

You need to meet NIS2, DORA, BNR, ASF, ADR or ANAF requirements

Audit Requirements

A client or auditor requests evidence of a security test

Technical Approval

You are preparing an approval or validation process

Security Validation

You want to check whether your security measures work

Risk Assessment

You need a realistic picture of technical risk

When you need a penetration test

Such a test is usually needed:

What we test

Web applications and platforms

We check applications and their user flows from the perspective of both a user and an attacker. We look for situations where data or functionality can be accessed without authorisation or manipulated.

APIs and integrations

APIs are often sensitive points in modern architectures. We analyse how they are protected, how access is validated and what happens if someone tries to exploit them.

Exposed infrastructure

We look at the systems visible from the outside: servers, services, administrative interfaces or VPNs. Here, we try to understand how easily an initial point of access can be obtained.

Internal infrastructure

We simulate what happens if an attacker gets inside.

We check whether they can:

move between systems
escalate privileges
reach critical data

Mobile applications

We test mobile applications and how they communicate with the backend. We look at authentication, data storage and the protection of communications.

Financial systems

For the financial sector, we test applications such as:

internet banking
mobile banking
payment platforms
financial APIs

Cloud and other components

Depending on the architecture, we can also include:

cloud infrastructure
databases
wireless networks
administration systems

Types of testing

Depending on how much context the organisation provides, testing can be:

Black Box

Testing is carried out without internal information about the systems being assessed, simulating the perspective of an external attacker. This approach shows how exposed the systems are from the perspective of someone trying to gain access without prior knowledge of the infrastructure.

Grey Box

Testing is carried out based on partial information or levels of access, set according to the objectives of the assessment. The approach combines the perspective of an external attacker with the available information, for a more efficient and detailed analysis of certain components

White Box

Testing is carried out with extensive access to the relevant information and components of the system, such as technical documentation, configurations or code, depending on the objectives of the assessment. This level of access allows for an in-depth analysis and the identification of vulnerabilities that are not always visible from the perspective of an external attacker.

Testing and compliance

Penetration testing is increasingly required in compliance contexts, but its value remains the same: it shows you the real risk.

It is particularly relevant for:

NIS2

Validation of technical controls in essential sectors.

DORA

Operational resilience in the financial sector.

BNR

Assessment of security and operational risk.

ASF

IT controls in insurance.

ADR and sector-specific requirements

Regulated services.

Funded projects

Security evidence for IT implementations.

How testing works

1. Defining the scope

We specify exactly what we test and under which conditions.

2. Understanding the systems

We look at the architecture and the exposed points.

3. Identifying vulnerabilities

We combine automated analysis with manual testing.

4. Assessing the impact

We try to see what can actually be exploited, not just what exists on paper.

5. Explaining the results

You receive a clear report, with priorities and recommendations.

6. Verifying the fixes (optional)

After remediation, we can validate whether the issues have been resolved.

What you get at the end

Test report
Identified vulnerabilities
Technical evidence
Risk level and impact
Remediation recommendations
Clear prioritisation
Management summary
Technical details for IT teams
Confirmation through retesting (if included)

Who this service is for

Testing is useful for organisations that:

Public Applications

Have publicly exposed applications or platforms.

Sensitive Data

Handle sensitive or critical data.

Compliance

Operate in a regulated field (NIS2, DORA, BNR, ASF, ADR, ANAF).

APIs

Develop or operate APIs.

Complex IT Projects

Implement complex or funded IT projects.

Security Requirements

Need to demonstrate security to partners or authorities.

Technical Validation

Want to check whether security measures actually work.

Concrete results

Why work with us?

Testing that validates real risks

We don’t stop at automated scans and vulnerability lists. We verify what can be exploited in practice, what the real impact is and what deserves priority treatment.

Official certification

We are a certified cybersecurity auditor (RENASC – IDASC QC-18310A7), recognised in regulated contexts such as BNR, ASF and ADR.

Easy-to-use reports

We have been working for more than 25 years in IT security, governance, risk and compliance, on complex and regulated projects.

0 +

Support after testing, too

Identifying vulnerabilities is only the first step. We help you understand the results, prioritise remediation and, if needed, later validate that the issues have been resolved.

FAQ

Frequently asked questions

Start with a simple assessment and receive concrete steps within 24h.

What is the difference between a pentest and a vulnerability scan?

A scan shows you possible issues. A pentest shows you what can actually be exploited and what impact it has.

Does testing affect the systems?

Testing is planned and carried out in a controlled manner, within the limits agreed with the client, to minimise the impact on systems and manage any risks.

How long does it take?

It depends on the systems in scope and the type of testing. We agree on it together after an initial discussion.

Is retesting necessary?

Retesting is recommended to confirm that fixes have been applied.

Does it guarantee security?

No. It gives you a realistic picture of security at the time of testing, within a defined scope.

Shall we talk?

If you want to understand what a real attack on your systems would look like and what that means for your organisation, we can define a suitable testing scenario together.

Simple, clear and applied to your context.