Domain · Pentests & configuration audits

A technical audit that ends with gaps fixed.

We scope the test or audit on what matters to you, help you choose the provider who carries it out, consolidate the findings with those of previous audits and track the fixes until the re-check. The report is only one step.

Situations

You are in the right place if…

  • You order a penetration test every year, and the same findings come back.
  • Your Microsoft 365 tenant was configured as you went, without a security review.
  • Your servers run on default settings.
  • A client or an authority requires a recent penetration test, and you do not know what scope to choose.
  • Several audit reports sit in a folder, without a consolidated action plan.
Our conviction

A technical audit is worth its scoping and the gaps it closes, not the report alone.

A badly scoped test misses your real risks; an unfollowed report reduces no risk. Too often, next year’s audit finds the same flaws.

So we scope each engagement on your risk scenarios, consolidate all findings into one plan, and track the fixes until they are re-checked. The next audit measures progress, not inertia.

Our approach

From scoping to re-check.

We do not carry out the tests ourselves: we scope them, help you choose and mandate the right provider, then put its findings to use.

  1. 01ScopeObjectives, scope, scenarios, production constraints and written authorisations.

    You getA specification and a test authorisation

  2. 02Choose the providerPenetration test, Microsoft 365 configuration review, system and server hardening: a provider suited to the scoping, whom you mandate.

    You getA provider selected and mandated

  3. 03ConsolidateFindings join those of previous audits, without duplicates, prioritised by risk.

    You getA single action plan

  4. 04Re-checkEach declared fix is checked against evidence, then re-tested by the provider; only then is the finding closed.

    You getA register of closed and open findings

What the texts say

What the texts expect of tests and audits.

The texts ask for regular tests and audits, but also that their results lead to corrective measures.

  • DORADORA art. 24(1) · DORA art. 25(1) · DORA art. 26(1)

    Financial entities, other than microenterprises, maintain a resilience testing programme to identify weaknesses and promptly remedy them; it includes appropriate tests, such as vulnerability assessments, source code reviews where feasible and penetration tests. Some entities carry out threat-led penetration testing (TLPT) at least every three years.123

  • NIS 2NIS 2 art. 21(2), point (f)

    The directive lists policies and procedures to assess the effectiveness of security measures among the measures Member States must require of entities.4

  • ReCyFReCyF v2.5, objectif 17 · ReCyF v2.5, objectif 18

    The ReCyF (working version) sets essential entities the objective of regular, planned security audits, and of a secure configuration of their resources, based on the recommendations of ANSSI or the vendor.56

  • GDPR · CNIL guideRGPD art. 32(1), point (d) · Guide CNIL sécurité, fiche 1, F01-MC-03

    The GDPR provides, as appropriate, for a process to regularly test the effectiveness of security measures; the CNIL recommends periodic audits, each followed by an action plan steered at the highest level.78

Our engagement

The same topic, at three levels of engagement.

You choose the level; the scope and deliverables are set by contract.

Level 01

Monitor

At agreed intervals, we track the state of findings and the evidence of fixes, and alert you to due dates.

Deliverables
  • Tracking of open findings
  • Check of the evidence of fixes
  • Alerts on due dates and audits to renew
Level 03

Drive

We run the handling of findings with your teams until the re-check, without making the changes in your systems.

Deliverables
  • Tracking of fixes and reminders
  • Re-check organised with the provider
  • Review ahead of the next audit
Accelerators

What we bring from day one.

Hardening baselines

Checklists for Microsoft 365, Windows, Linux and common servers, based on published recommendations, to scope the audit and track the fixes.

Scoping templates

Specification, authorisation agreement and a grid for choosing a penetration testing provider.

Choosing the test provider

With the Expert Connect option, we shortlist penetration testing and configuration audit providers; you choose and you mandate.

Frequently asked questions

Before we start.

Do you carry out the tests and audits yourselves?

No. We scope the need, help you choose and mandate a provider suited to the scope and the qualifications required, then fold its findings into the action plan and track the fixes. Our view thus stays independent of whoever tests.

Are we subject to threat-led penetration testing (TLPT)?

Only certain financial entities, identified under DORA’s criteria, are subject to it, at least every three years. We help you check whether you are one of them, to confirm with your authority or your legal counsel.3

Can the test affect production?

Scoping sets in writing, with the provider, the scope, the techniques allowed, the slots and the emergency contacts; risky tests run outside production or under supervision.

What about findings we will not fix?

They stay in the register, with an explicit risk acceptance, an owner and a review date. The next audit finds them again, but as decisions, not oversights.

Start with the scoping.

Describe the scope you have in mind and your latest reports. We come back to you with a scoping proposal.

Sources

The excerpts quoted.

Exact text, in its original language, from the frameworks extracted from the official text.

Show the 8 excerpts quoted
  1. 1DORA art. 24(1)32022R2554-a24-p1
    For the purpose of assessing preparedness for handling ICT-related incidents, of identifying weaknesses, deficiencies and gaps in digital operational resilience, and of promptly implementing corrective measures, financial entities, other than microenterprises, shall, taking into account the criteria set out in Article 4(2), establish, maintain and review a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk-management framework referred to in Article 6.
    Normative force
    directly applicable EU law (regulation, level 1)
    Source
    Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector
    Version
    CELEX 32022R2554 — ELI reg/2022/2554
    Official text
  2. 2DORA art. 25(1)32022R2554-a25-p1
    The digital operational resilience testing programme referred to in Article 24 shall provide, in accordance with the criteria set out in Article 4(2), for the execution of appropriate tests, such as vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing.
    Normative force
    directly applicable EU law (regulation, level 1)
    Source
    Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector
    Version
    CELEX 32022R2554 — ELI reg/2022/2554
    Official text
  3. 3DORA art. 26(1)32022R2554-a26-p1
    Financial entities, other than entities referred to in Article 16(1), first subparagraph, and other than microenterprises, which are identified in accordance with paragraph 8, third subparagraph, of this Article, shall carry out at least every 3 years advanced testing by means of TLPT. Based on the risk profile of the financial entity and taking into account operational circumstances, the competent authority may, where necessary, request the financial entity to reduce or increase this frequency.
    Normative force
    directly applicable EU law (regulation, level 1)
    Source
    Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector
    Version
    CELEX 32022R2554 — ELI reg/2022/2554
    Official text
  4. 4NIS 2 art. 21(2), point (f)32022L2555-a21-p2-6
    policies and procedures to assess the effectiveness of cybersecurity risk-management measures;
    Normative force
    EU law to be transposed (directive): not directly applicable, requires national transposition
    Source
    Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive)
    Version
    CELEX 32022L2555 — ELI dir/2022/2555
    Official text
  5. 5ReCyF v2.5, objectif 17recyf:obj-17
    Les entités [essentielles] réalisent ou font réaliser à intervalles réguliers et planifiés des audits de sécurité de leurs systèmes d’information. Ces audits doivent permettre de vérifier l’atteinte des objectifs [de sécurité] et d’évaluer le niveau de sécurité de leurs systèmes d’information.
    Normative force
    obligation (decree, resilience bill)
    Source
    ReCyF — Référentiel Cyber France (NIS 2, transposition nationale)
    Version
    2.5 du 17/03/2026 (version de travail)
    Status
    Working version: not binding until the transposition is enacted
    Official text
  6. 6ReCyF v2.5, objectif 18recyf:obj-18
    Les entités [essentielles] limitent la surface d'attaque des composants de leurs systèmes d’information. Pour ce faire, elles s’assurent que seules les ressources logicielles nécessaires à la réalisation de leurs activités et services ou au maintien en condition opérationnelle ou de sécurité sont installées ou conservées sur leurs systèmes d’information, et elles configurent les ressources de leurs systèmes d’information de manière sécurisée en s’appuyant sur les recommandations de l’autorité nationale de sécurité des systèmes d’information, de l’éditeur de la fonctionnalité ou du fabricant de la ressource..
    Normative force
    obligation (decree, resilience bill)
    Source
    ReCyF — Référentiel Cyber France (NIS 2, transposition nationale)
    Version
    2.5 du 17/03/2026 (version de travail)
    Status
    Working version: not binding until the transposition is enacted
    Official text
  7. 7RGPD art. 32(1), point (d)32016R0679-a32-p1-4
    a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.
    Normative force
    directly applicable EU law (regulation, level 1)
    Source
    Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)
    Version
    CELEX 32016R0679 — ELI reg/2016/679
    Official text
  8. 8Guide CNIL sécurité, fiche 1, F01-MC-03F01-MC-03
    Les audits de sécurité sont un moyen essentiel pour évaluer le niveau de sécurité des systèmes sur lesquels reposent le(s) traitement(s) de données personnelles. Réalisés de façon périodique, ils permettent de prendre en compte les évolutions du traitement et des menaces. Chaque audit doit donner lieu à un plan d’action dont la mise en œuvre devrait être suivie au plus haut niveau de l’organisme.
    Normative force
    recommendation (soft law)
    Source
    Guide pratique RGPD — Sécurité des données personnelles
    Version
    2024 (mise à jour 2026)
    Official text