Combien de Travail Represente CyFun Basic ? Une Vraie Implementation de 11 Semaines, Mesuree
La Belgique compte plus de 4.000 entites enregistrees 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 implementation, entierement instrumentee. Chaque action dans notre plateforme est un evenement 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'honnetete d'emblee : voyez la plateforme comme un tableau de score, pas comme la salle de sport. Elle enregistre le moment ou quelque chose est consigne ; le travail reel derriere chaque entree, et ses nombreuses heures, se passe hors plateforme ou aucun journal ne le voit.
Onze semaines a un jour par semaine : le calendrier d'activite
Lisez ceci comme un graphique de contributions GitHub : une cellule par jour, plus fonce veut dire plus. Le calendrier vert est l'humain : 26 sessions, environ un vrai jour de travail par semaine, avec une grosse journee d'inventaire le 11 mai. Le calendrier bleu est la plateforme : une fois les integrations connectees (du 8 au 18 mai), la collecte automatique de preuves continue, que quelqu'un se connecte ou non.
Ce qui s'est passe, en quatre phases
1. Cadrage (30 mars, une matinee)
Onboarding, le controle de niveau CyFun et les premiers squelettes de politiques. Le controle recommande BASIC pour la taille et le profil de risque de cette organisation.
2. Intake (avril)
L'evaluation guidee : 90 reponses sur le fonctionnement reel de l'organisation. Le 20 avril, la plateforme etablit une premiere base de maturite sur les 34 controles.
3. Construction (mai)
Les semaines lourdes. Les inventaires arrivent via les integrations et un import CSV ; l'implementeur decide de ce qui est critique pour l'entreprise, finalise 8 politiques et procedures, et connecte Microsoft 365 et la securite endpoint. A partir du 21 mai, la collecte automatique de preuves tourne.
4. Juger et cloturer (juin)
La partie que seul un humain peut faire : revoir chaque controle, accepter ou corriger les scores, et consulter un expert la ou une interpretation juridique etait necessaire. Etat final le 17 juin : 31 des 34 controles prets pour l'audit, 3 attendus en echec, honnetement etiquetes comme tels.
Ou sont allees les 672 actions manuelles
Aucun des grands blocs ne demande une expertise en securite. Ils demandent de connaitre sa propre organisation.
| Type de travail | Actions manuelles |
|---|---|
| Decider ce qui est critique (grouper actifs et personnes) | 153 |
| Traiter les preuves (upload, liaison, revue) | 133 |
| Repondre a l'evaluation d'intake | 90 |
| Onboarding et squelettes de politiques | 67 |
| Rediger politiques et procedures (8 documents) | 64 |
| Editions de registres et imports CSV | 60 |
| Scores de maturite et acceptation | 30 |
| Tout le reste (exports, connexions, exceptions) | 25 |
Les actions enregistrees sous des comptes utilisateurs par les synchronisations d'integrations 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 ete ecrits et tenus a 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 journee. 19 des 34 controles ont termine le projet entierement scores sur preuves automatisees, 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 apres le projet : l'effort de construction arrive une fois, mais la fraicheur des preuves est ce qu'un auditeur verifie. Les 19 controles automatises restent a jour sans que personne ne passe son vendredi a faire des captures d'ecran.
Ou un non-specialiste a bute
Un schema merite l'honnetete. Le controle qui a pris le plus de temps entre premier contact et validation (GV.OC-03.1, le registre legal et reglementaire) etait aussi celui ou l'implementeur a explicitement eu besoin d'un expert, deux fois. Determiner quelles lois s'appliquent a votre organisation n'est pas une tache de checklist. Les controles techniques et proceduraux ont ete termines sans cette aide. C'est une observation issue d'une implementation, pas une loi de la nature, mais elle correspond a la bonne repartition du travail : l'automatisation et le guidage portent la routine, le temps d'expert va la ou le jugement est rare.
Modelise : integrations connectees des le premier jour
Cette implementation etait mixte : les inventaires ont d'abord ete construits a la main et par import CSV (la grosse journee d'inventaire du 11 mai), puis les integrations ont pris le relais. Modelise sur les donnees mesurees, connecter les integrations en semaine une supprime l'essentiel de ce travail de registre. Mais la plus grande difference n'est pas le temps de construction. C'est qu'une fois les integrations actives, les inventaires et les preuves restent continuellement a jour, sans que personne ne se connecte.
Les 34 controles : resultat et chronologie
Chaque controle a recu son premier score le 20 avril. La colonne derniere activite montre quels controles ont encore eu besoin d'un humain en juin, et lesquels l'automatisation a clotures tot.
| Controle | Ce qu'il couvre | Resultat | Premiere / derniere activite |
|---|---|---|---|
| GV.OC-03.1 | Legal & regulatory register | Juge par un humain | 20 Apr → 9 Jun |
| GV.PO-01.1 | Policy framework | Preuves automatisees | 20 Apr → 9 Jun |
| GV.RM-03.1 | Risk strategy | Preuves automatisees | 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 automatisees | 20 Apr → 8 May |
| ID.AM-02.1 | Software inventory | Preuves automatisees | 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 automatisees | 20 Apr → 7 May |
| ID.RA-01.1 | Threat & vulnerability identification | Preuves automatisees | 20 Apr → 2 Jun |
| ID.RA-05.1 | Risk assessment | Preuves automatisees | 20 Apr → 22 Apr |
| ID.IM-03.1 | Post-incident lessons | Preuves automatisees | 20 Apr → 22 Apr |
| PR.AA-01.1 | Identity & credential management | Preuves automatisees | 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 automatisees | 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 automatisees | 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 automatisees | 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 automatisees | 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 automatisees | 20 Apr → 28 May |
| PR.IR-01.1 | Firewalls | Preuves automatisees | 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 automatisees | 20 Apr → 2 Jun |
| DE.CM-01.2 | Anti-malware | Preuves automatisees | 20 Apr → 5 Jun |
| DE.CM-03-1 | Behaviour monitoring | Preuves automatisees | 20 Apr → 22 Apr |
| DE.AE-03.1 | Detection log review | Preuves automatisees | 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 |
Resultat selon l'etat du 29 juin ; les etats des controles continuent d'evoluer avec les preuves automatisees. Le titre de 91% est l'evaluation datee du 17 juin, qui marquait 3 controles comme attendus en echec. Pret pour l'audit signifie que les preuves resisteraient plausiblement a la revue d'un auditeur CAB ; l'audit lui-meme est realise par un CAB accredite.
Ce que cela signifie si NIS2 s'applique a vous
- 1 Si vous etes une petite entite qui redoute un devis de consultance : cela s'est etale sur environ onze semaines a peu pres un jour par semaine. C'est un projet, pas une reconversion. L'essentiel de l'effort reel, c'est configurer votre environnement et ecrire vos procedures, hors plateforme ; le role de la plateforme est de vous dire exactement ce qu'il faut et de le prouver une fois fait.
- 2 Si vous etes un MSP ou partenaire IT : un junior peut piloter ceci pour vos clients. Ce que vous vendez vraiment, c'est la couche de jugement : decisions de criticite, validation des politiques et questions juridiques, pas la saisie de donnees.
- 3 Si vous voulez des donnees plutot que des promesses : chaque implementation sur la plateforme est instrumentee de la meme facon. Demandez la methode, ou mesurez la votre.
Questions Frequentes
Est-ce que 91% pret pour l'audit egale conforme NIS2 ?
Non. Pret pour l'audit signifie que chaque controle a une implementation plus des preuves qui resisteraient plausiblement a la revue d'un auditeur CAB, tel qu'evalue dans la plateforme. L'audit lui-meme est realise par un Conformity Assessment Body. L'evaluation du 17 juin marquait aussi 3 des 34 controles comme attendus en echec, visibles et honnetement etiquetes plutot que caches.
Quelqu'un sans experience en cybersecurite peut-il vraiment faire cela ?
Cette implementation est une preuve d'existence que c'est arrive une fois : une personne sans experience prealable en cybersecurite ou conformite, guidee controle par controle, a environ un jour par semaine. La ou de l'aide a ete necessaire, c'etait specifique : l'interpretation juridique (quelles lois s'appliquent). Le travail technique et procedural a ete termine sans expert.
Une seule implementation prouve-t-elle que cela marche pour tous ?
Non, et nous ne le pretendons pas. C'est un cas mesure, publie avec sa methode et ses limites. Chaque implementation sur la plateforme est instrumentee de la meme maniere, donc le jeu de donnees grandit a chaque fois. Nous preferons publier un point de donnee honnete qu'une moyenne inverifiable.
Qu'est-ce qui reste manuel, meme avec une automatisation complete ?
Connaitre sa propre organisation : decider quels actifs et quelles personnes sont critiques (le plus grand bloc de travail manuel, 153 actions), revoir et accepter les scores de maturite, le contenu des politiques, et les questions d'interpretation juridique. L'automatisation ecrit 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 honnetement. La plateforme stocke chaque changement comme un evenement, 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 meme temps, donc l'amplitude d'une journee n'est pas du temps passe sur la conformite. La raison plus importante : le travail reel ne laisse aucun evenement. Activer le MFA, installer des pare-feux, ecrire et executer des procedures, rassembler les preuves. Cela se passe hors plateforme. Nous rapportons la duree et les comptes, que nous pouvons defendre, et laissons le chronometre de cote.
De quoi les trois controles non prets avaient-ils besoin ?
De vrais changements organisationnels que le logiciel peut signaler mais pas executer. La plateforme marque ces controles comme attendus en echec plutot que de les embellir, parce qu'un 91% honnete avec une liste de taches vaut mieux qu'un faux 100%.