We measure, read-only from your XDR console, what your monitoring actually sees: log sources that keep reporting, attack techniques covered, alert quality, the provider’s responsiveness. Then we track improvements until they are verified.
A SOC only detects what it receives, with the rules it applies. A log source gone silent, a disabled rule or a badly set threshold is enough to make an attack invisible, without the reports saying so.
So we start from the facts in your console, not from the provider’s reports: which sources went silent, which rules fire, which attack techniques produced no alert, how long each alert takes to be acknowledged and resolved. Then we relate them to the threats your activities face.
We work with your provider, not in its place, and change nothing in your systems: we measure the set-up, not the people.
You getPriority threats and the techniques they involve
You getA coverage matrix by technique, and measured response times
You getDated test results
You getAn improvement plan and its follow-up
The texts do not only ask you to monitor: they ask for tested mechanisms, defined thresholds and sufficient resources.
Financial entities must have mechanisms to promptly detect anomalous activities, regularly tested.1
These mechanisms provide multiple layers of control, alert thresholds and criteria that trigger incident response, and sufficient resources to monitor activity.23
The directive lists incident handling among the measures Member States must require of entities; the ReCyF (working version) sets them the objective of having an organisation, processes and tools to prepare for and respond to security events.45
The CNIL recommends logging user activity, technical interventions and security events, and regularly checking that usable logs are present.67
The texts do not apply to every organisation: whether they apply depends on your status, your sector, your size and your contracts. Have it confirmed by your legal counsel or a specialised lawyer.
You choose the level; the scope and deliverables are set by contract.
We continuously measure the coverage and responsiveness of monitoring, and document the gaps.
DeliverablesWe analyse the gaps, the provider’s decisions and reports, and help you decide on priorities.
DeliverablesWe run the follow-up of improvements with your teams and your provider, without making the changes in your systems.
DeliverablesConnected to your XDR console with a read-only key: source health, ATT&CK coverage, provider response times by severity and month, recomputed continuously. Cortex XDR today; Sophos and Trend Vision One being validated.
Closed alerts reviewed decision by decision, rules that only produce noise, recurring false positives never fixed.
A weekly annotated report, findings tied to their evidence, and for each one an owner, a due date and a history.
No. We are not a SOC. We measure what your set-up detects and help you improve it with your provider, who remains in charge of monitoring and response.
Cortex XDR, directly through its API. The Sophos and Trend Vision One connectors are built and being validated with a first client. For other tools, we work from exports.
For a financial entity subject to DORA, yes: the regulation requires detection mechanisms to be regularly tested. For other organisations, it is the only way to know what monitoring really sees.1
Offered as an option, they are designed to be harmless: they imitate the trace of an attack without its effect. Their scope, timing and the people informed are agreed in writing before any test.
A read-only API key on your XDR console, which gives log sources, alerts and incidents. We do not need administrator rights. Some tools do not let that kind of key read rule configuration: we then ask your provider for an export.
Using your XDR console or available exports, identify silent log sources, documented coverage, alerts actually observed and response times. Get prioritised gaps to discuss with your provider and a practical improvement plan. We can start with a focused baseline and compare results after 30 days where data allows. Read-only access, scope and price by quote; detection tests are optional and require written approval.
Exact text, in its original language, from the frameworks extracted from the official text.
32022R2554-a10-p1Financial entities shall have in place mechanisms to promptly detect anomalous activities, in accordance with Article 17, including ICT network performance issues and ICT-related incidents, and to identify potential material single points of failure. All detection mechanisms referred to in the first subparagraph shall be regularly tested in accordance with Article 25.32022R2554-a10-p2The detection mechanisms referred to in paragraph 1 shall enable multiple layers of control, define alert thresholds and criteria to trigger and initiate ICT-related incident response processes, including automatic alert mechanisms for relevant staff in charge of ICT-related incident response.32022R2554-a10-p3Financial entities shall devote sufficient resources and capabilities to monitor user activity, the occurrence of ICT anomalies and ICT-related incidents, in particular cyber-attacks.32022L2555-a21-p2-2incident handling;recyf:obj-12Les entités [importantes ou essentielles] mettent en œuvre une organisation, des processus et des outils adaptés pour se préparer et réagir à des événements de sécurité susceptibles d’affecter la réalisation de leurs activités ou la fourniture de leurs services.F16-PE-01Prévoir un système de journalisation (c’est-à-dire un enregistrement dans des fichiers journaux ou « logs ») des activités métier des utilisateurs (traces applicatives), des interventions techniques (y compris par les administrateurs), des anomalies et des évènements liés à la sécurité (traces techniques ou « système »).F16-PE-06S’assurer du bon fonctionnement du système de journalisation en intégrant les équipements dans un outil de supervision et vérifier régulièrement la présence de journaux exploitables.