Combien de Travail Représente CyFun Basic ? Une Vraie Implémentation de 11 Semaines, Mesuree
La Belgique compte plus de 4.000 entités enregistrées sous NIS2, et la plupart des conseils sur CyberFundamentals parlent en mois et en budgets de consultance. Nous avions quelque chose de plus rare : une vraie implémentation, entièrement instrumentee. Chaque action dans notre plateforme est un événement avec un acteur et un horodatage. Au lieu de demander combien de temps cela a pris, nous avons exporte le journal et compte. Une note d'honnêteté d'emblee : voyez la plateforme comme un tableau de score, pas comme la salle de sport. Elle enregistré le moment ou quelque chose est consigné ; le travail réel derrière chaque entrée, et ses nombreuses heures, se passe hors plateforme ou aucun journal ne le voit.
Onze semaines a un jour par semaine : le calendrier d'activité
Lisez ceci comme un graphique de contributions GitHub : une cellule par jour, plus foncé veut dire plus. Le calendrier vert est l'humain : 26 sessions, environ un vrai jour de travail par semaine, avec une grosse journée d'inventaire le 11 mai. Le calendrier bleu est la plateforme : une fois les intégrations connectees (du 8 au 18 mai), la collecte automatique de preuves continue, que quelqu'un se connecté ou non.
Ce qui s'est passe, en quatre phases
1. Cadrage (30 mars, une matinee)
Onboarding, le contrôle de niveau CyFun et les premiers squelettes de politiques. Le contrôle recommande BASIC pour la taille et le profil de risque de cette organisation.
2. Intake (avril)
L'évaluation guidée : 90 réponses sur le fonctionnement réel de l'organisation. Le 20 avril, la plateforme établit une première base de maturité sur les 34 contrôles.
3. Construction (mai)
Les semaines lourdes. Les inventaires arrivent via les intégrations et un import CSV ; l'implementeur decide de ce qui est critique pour l'entreprise, finalise 8 politiques et procédures, et connecté Microsoft 365 et la sécurité endpoint. A partir du 21 mai, la collecte automatique de preuves tourne.
4. Juger et clôturer (juin)
La partie que seul un humain peut faire : revoir chaque contrôle, accepter ou corriger les scores, et consulter un expert la ou une interprétation juridique était nécessaire. État final le 17 juin : 31 des 34 contrôles prêts pour l'audit, 3 attendus en échec, honnêtement étiquetés comme tels.
Ou sont allees les 672 actions manuelles
Aucun des grands blocs ne demande une expertise en sécurité. Ils demandent de connaitre sa propre organisation.
| Type de travail | Actions manuelles |
|---|---|
| Décider ce qui est critique (grouper actifs et personnes) | 153 |
| Traiter les preuves (upload, liaison, revue) | 133 |
| Répondre a l'évaluation d'intake | 90 |
| Onboarding et squelettes de politiques | 67 |
| Rédiger politiques et procédures (8 documents) | 64 |
| Editions de registres et imports CSV | 60 |
| Scores de maturité et acceptation | 30 |
| Tout le reste (exports, connexions, exceptions) | 25 |
Les actions enregistrées sous des comptes utilisateurs par les synchronisations d'intégrations et le traitement propre de la plateforme comptent comme de l'automatisation, pas comme du travail manuel.
Ce que la plateforme a fait toute seule
Pour chaque action manuelle, la plateforme en a execute sept. Les registres d'actifs (appareils, personnes, applications) ont été écrits et tenus à jour par les synchronisations ; le travail de registre de l'implementeur s'est limite a environ 60 editions et actions CSV, en grande partie sur une seule journée. 19 des 34 contrôles ont termine le projet entièrement scores sur preuves automatisées, sans correction manuelle.
Depuis la mise en service de la collecte automatique le 21 mai, la plateforme a materialise plus de 1.300 preuves toute seule. C'est la partie qui compte après le projet : l'effort de construction arrive une fois, mais la fraicheur des preuves est ce qu'un auditeur vérifie. Les 19 contrôles automatisés restent à jour sans que personne ne passe son vendredi a faire des captures d'écran.
Ou un non-specialiste a buté
Un schéma mérite l'honnêteté. Le contrôle qui a pris le plus de temps entre premier contact et validation (GV.OC-03.1, le registre légal et réglementaire) était aussi celui ou l'implementeur a explicitement eu besoin d'un expert, deux fois. Déterminer quelles lois s'appliquent à votre organisation n'est pas une tâche de checklist. Les contrôles techniques et proceduraux ont été termines sans cette aide. C'est une observation issue d'une implémentation, pas une loi de la nature, mais elle correspond à la bonne répartition du travail : l'automatisation et le guidage portent la routine, le temps d'expert va la ou le jugement est rare.
Modelise : intégrations connectees dès le premier jour
Cette implémentation était mixte : les inventaires ont d'abord été construits à la main et par import CSV (la grosse journée d'inventaire du 11 mai), puis les intégrations ont pris le relais. Modelise sur les données mesurees, connecter les intégrations en semaine une supprimé l'essentiel de ce travail de registre. Mais la plus grande différence n'est pas le temps de construction. C'est qu'une fois les intégrations actives, les inventaires et les preuves restent continuellement à jour, sans que personne ne se connecté.
Les 34 contrôles : résultat et chronologie
Chaque contrôle a reçu son premier score le 20 avril. La colonne dernière activité montre quels contrôles ont encore eu besoin d'un humain en juin, et lesquels l'automatisation a clotures tôt.
| Contrôle | Ce qu'il couvre | Résultat | Première / dernière activité |
|---|---|---|---|
| GV.OC-03.1 | Legal & regulatory register | Juge par un humain | 20 Apr → 9 Jun |
| GV.PO-01.1 | Policy framework | Preuves automatisées | 20 Apr → 9 Jun |
| GV.RM-03.1 | Risk strategy | Preuves automatisées | 20 Apr → 7 May |
| GV.RR-04.1 | Authentication for critical access | Juge par un humain | 20 Apr → 5 Jun |
| ID.AM-01.1 | Hardware inventory | Preuves automatisées | 20 Apr → 8 May |
| ID.AM-02.1 | Software inventory | Preuves automatisées | 20 Apr → 7 May |
| ID.AM-5.1 | Asset prioritisation | Juge par un humain | 20 Apr → 8 Jun |
| ID.AM-07.1 | Data identification | Juge par un humain | 20 Apr → 9 Jun |
| ID.AM-08.2 | Patching | Preuves automatisées | 20 Apr → 7 May |
| ID.RA-01.1 | Threat & vulnerability identification | Preuves automatisées | 20 Apr → 2 Jun |
| ID.RA-05.1 | Risk assessment | Preuves automatisées | 20 Apr → 22 Apr |
| ID.IM-03.1 | Post-incident lessons | Preuves automatisées | 20 Apr → 22 Apr |
| PR.AA-01.1 | Identity & credential management | Preuves automatisées | 20 Apr → 7 May |
| PR.AA-03.1 | Wireless access points | Juge par un humain | 20 Apr → 2 Jun |
| PR.AA-03.2 | Remote MFA | Juge par un humain | 20 Apr → 4 Jun |
| PR.AA-05.1 | Access permissions | Preuves automatisées | 20 Apr → 7 May |
| PR.AA-05.2 | Access needs determination | Juge par un humain | 20 Apr → 9 Jun |
| PR.AA-05.3 | Least privilege | Preuves automatisées | 20 Apr → 7 May |
| PR.AA-05.4 | No routine admin rights | Juge par un humain | 20 Apr → 5 Jun |
| PR.AA-06.1 | Physical access | Preuves automatisées | 20 Apr → 7 May |
| PR.AT-01.1 | Awareness & training | Juge par un humain | 20 Apr → 28 May |
| PR.DS-01.9 | Asset disposal | Preuves automatisées | 20 Apr → 7 May |
| PR.DS-11.1 | Off-system backups | Juge par un humain | 20 Apr → 5 Jun |
| PR.PS-04.1 | Log monitoring | Juge par un humain | 20 Apr → 9 Jun |
| PR.PS-05.1 | Web & e-mail filters | Preuves automatisées | 20 Apr → 28 May |
| PR.IR-01.1 | Firewalls | Preuves automatisées | 20 Apr → 7 May |
| PR.IR-01.2 | Network segmentation | Juge par un humain | 20 Apr → 5 Jun |
| DE.CM-01.1 | Boundary & endpoint firewalls | Preuves automatisées | 20 Apr → 2 Jun |
| DE.CM-01.2 | Anti-malware | Preuves automatisées | 20 Apr → 5 Jun |
| DE.CM-03-1 | Behaviour monitoring | Preuves automatisées | 20 Apr → 22 Apr |
| DE.AE-03.1 | Detection log review | Preuves automatisées | 20 Apr → 22 Apr |
| RS.MA-01.1 | Incident response plan | Juge par un humain | 20 Apr → 5 Jun |
| RS.CO-02.1 | Incident communication | Juge par un humain | 20 Apr → 5 Jun |
| RC.RP-01.1 | Recovery process | Juge par un humain | 20 Apr → 15 Jun |
Résultat selon l'état du 29 juin ; les états des contrôles continuent d'évoluer avec les preuves automatisées. Le titre de 91% est l'évaluation datee du 17 juin, qui marquait 3 contrôles comme attendus en échec. Prêt pour l'audit signifie que les preuves resisteraient plausiblement à la revue d'un auditeur CAB ; l'audit lui-même est réalisé par un CAB accrédité.
Ce que cela signifie si NIS2 s'applique à vous
- 1 Si vous êtes une petite entité qui redoute un devis de consultance : cela s'est etale sur environ onze semaines a peu près un jour par semaine. C'est un projet, pas une reconversion. L'essentiel de l'effort réel, c'est configurer votre environnement et écrire vos procédures, hors plateforme ; le rôle de la plateforme est de vous dire exactement ce qu'il faut et de le prouver une fois fait.
- 2 Si vous êtes un MSP ou partenaire IT : un junior peut piloter ceci pour vos clients. Ce que vous vendez vraiment, c'est la couche de jugement : décisions de criticité, validation des politiques et questions juridiques, pas la saisie de données.
- 3 Si vous voulez des données plutôt que des promesses : chaque implémentation sur la plateforme est instrumentee de la même façon. Demandez la méthode, ou mesurez la votre.
Questions Fréquentes
Est-ce que 91% prêt pour l'audit egale conforme NIS2 ?
Non. Prêt pour l'audit signifie que chaque contrôle à une implémentation plus des preuves qui resisteraient plausiblement à la revue d'un auditeur CAB, tel qu'évalué dans la plateforme. L'audit lui-même est réalisé par un Conformity Assessment Body. L'évaluation du 17 juin marquait aussi 3 des 34 contrôles comme attendus en échec, visibles et honnêtement étiquetés plutôt que cachés.
Quelqu'un sans expérience en cybersécurité peut-il vraiment faire cela ?
Cette implémentation est une preuve d'existence que c'est arrive une fois : une personne sans expérience préalable en cybersécurité ou conformité, guidée contrôle par contrôle, a environ un jour par semaine. La ou de l'aide a été nécessaire, c'était spécifique : l'interprétation juridique (quelles lois s'appliquent). Le travail technique et procedural a été termine sans expert.
Une seule implémentation prouve-t-elle que cela marche pour tous ?
Non, et nous ne le pretendons pas. C'est un cas mesure, publie avec sa méthode et ses limites. Chaque implémentation sur la plateforme est instrumentee de la même manière, donc le jeu de données grandit à chaque fois. Nous preferons publier un point de donnée honnête qu'une moyenne inverifiable.
Qu'est-ce qui reste manuel, même avec une automatisation complète ?
Connaitre sa propre organisation : décider quels actifs et quelles personnes sont critiques (le plus grand bloc de travail manuel, 153 actions), revoir et accepter les scores de maturité, le contenu des politiques, et les questions d'interprétation juridique. L'automatisation écrit et rafraichit inventaires et preuves ; elle ne sait pas ce qui compte pour votre entreprise.
Pourquoi ne pas rapporter les heures d'effort ?
Parce que nous ne pouvons pas les mesurer honnêtement. La plateforme stocke chaque changement comme un événement, donc nous pouvons compter les actions (672 manuelles) et les jours ou elles ont eu lieu (26), mais pas les minutes entre elles. L'implementeur tenait un help desk en même temps, donc l'amplitude d'une journée n'est pas du temps passe sur la conformité. La raison plus importante : le travail réel ne laisse aucun événement. Activer le MFA, installer des pare-feux, écrire et exécuter des procédures, rassembler les preuves. Cela se passe hors plateforme. Nous rapportons la durée et les comptes, que nous pouvons defendre, et laissons le chronometre de cote.
De quoi les trois contrôles non prêts avaient-ils besoin ?
De vrais changements organisationnels que le logiciel peut signaler mais pas exécuter. La plateforme marque ces contrôles comme attendus en échec plutôt que de les embellir, parce qu'un 91% honnête avec une liste de tâches vaut mieux qu'un faux 100%.