Reglyze is built on Reglyze

La PSSI (REGLYZE-ISP-001) et le board briefing deck matérialisent un système de management de la sécurité approuvé par le dirigeant ; structure mono-dirigeant, cadence de revue formelle non testée (v1.0). [NIS2 20.1.a, 21.2.a.2]

Les rôles et responsabilités sécurité sont décrits dans l'ISP et le board deck ; avec 5 personnes et un dirigeant unique, la matrice de délégation/organisation formalisée reste embryonnaire. [NIS2 20.1.a]

La politique RH (hr_security) couvre screening, arrivée et départ ; aucune charte signée, checklist d'onboarding ou journal NDA complété n'est attesté pour les 5 collaborateurs. [NIS2 21.2.i.4]

Le plan de formation couvre la sensibilisation de l'ensemble des 5 collaborateurs et du dirigeant ; aucun enregistrement de complétion (certificat, log LMS) n'existe. [NIS2 21.2.g.1]

La politique de contrôle d'accès (REG-SEC-POL-001) documente le moindre privilège et la MFA est imposée partout (FORCE) ; aucun cycle de revue des accès n'a toutefois été complété. [NIS2 21.2.i.2, 21.2.j.1]

La politique de test d'efficacité (REG-POL-ETP-001) définit la gestion des exigences et l'auto-évaluation NIS2 de mai 2026 en est l'application (dogfooding) ; aucun cycle d'audit/conformité complété. [NIS2 21.2.f]

FORCE : chiffrement au repos opérationnel (Postgres/Redis/MinIO/sauvegardes) et TLS imposé en transit via Cloudflare, adossés à la politique de chiffrement (REG-SEC-POL-CRYPTO-001) v1.0. [NIS2 21.2.h.2, 21.2.h.3]

La protection des données repose sur le chiffrement et le contrôle d'accès ; posture RGPD réelle mais aucune politique de protection des données autonome ni DPA fournisseur exécuté. [NIS2 21.2.h, 21.2.i]

Sauvegardes quotidiennes rclone -> Google Drive opérationnelles, adossées à la politique BDR (REGLYZE-POL-BDR-001) ; la restauration n'a pas été testée sur les 12 derniers mois. [NIS2 21.2.c.2]

L'effacement relève du RGPD applicatif mais aucune procédure d'effacement/destruction sécurisée formalisée ni journal n'est attesté (infra cloud, pas de média physique). [NIS2 21.2.i]

Développement sur monorepo TypeScript avec revue de PR et CI/CD GitHub ; Dependabot/Renovate couvrent les dépendances, mais aucun cycle de développement sécurisé (SDLC) formellement documenté. [NIS2 21.2.e.1]

Les échanges d'information sont chiffrés (TLS) et la politique MFA/communications sécurisées (REGLYZE-POL-SEC-007) référence les canaux ; aucun accord d'échange formel avec des tiers. [NIS2 21.2.j]

Le produit web bénéficie de TLS + WAF Cloudflare, du blocage egress (correctif SSRF S2) et de la CSP (S5) ; aucun standard de développement web-app documenté ni test d'intrusion. [NIS2 21.2.e]

L'exploitation IT est conteneurisée et pilotée par CI/CD GitHub (déploiements reproductibles) ; aucun manuel d'exploitation formalisé. [NIS2 21.2.e]

L'administration passe par SSH/consoles avec MFA imposée et comptes nominatifs ; aucun concept d'administration (droits admin, séparation des tâches) formellement documenté. [NIS2 21.2.e, 21.2.i.2]

FORCE opérationnelle : Dependabot + Renovate ouvrent des PR de correctifs automatiques (3 PR de sécurité réelles appliquées, SLA de patch 100%), adossés à la politique de gestion des vulnérabilités (REG-SEC-POL-003). [NIS2 21.2.e.3]

Pas d'AV/EDR sur serveurs (infra conteneurisée immuable) ; le WAF Cloudflare filtre les menaces web mais aucun programme anti-malware documenté. [NIS2 21.2.e]

Journaux GitHub, logs de déploiement et logs applicatifs/DB existent avec centralisation partielle (log-shipper) ; pas de SIEM ni de politique de journalisation formelle. [NIS2 21.2.e.5, 21.2.b.2]

Tests automatisés et revue de PR conditionnent la mise en production via CI/CD ; aucune procédure formelle d'approbation de mise en production documentée. [NIS2 21.2.e.1]

La gestion des systèmes s'appuie sur Docker Compose et une configuration versionnée (compose/ADRs) ; pas de concept de gestion des systèmes formalisé. [NIS2 21.2.e]

Les sauvegardes quotidiennes assurent une rétention mais aucun concept d'archivage distinct (valeur probante, conservation long-terme) n'est formalisé. [pas d'évidence directe]

Équipe 100% distante avec MFA et chiffrement des postes ; le télétravail est couvert de façon informelle par la politique RH, sans politique de télétravail dédiée. [NIS2 21.2.i]

La télémaintenance vers l'hôte Hetzner passe par Cloudflare Tunnel/SSH chiffrés avec MFA imposée ; procédure non formellement documentée. [NIS2 21.2.j.1, 21.2.e]

La synchronisation NTP est assurée au niveau OS de l'hôte Linux mais n'est ni durcie ni documentée comme mesure. [pas d'évidence directe]

7 fournisseurs cloud identifiés et évalués (Hetzner, Cloudflare, Anthropic, Stripe, GitHub, Resend, Google) avec criticité et risque résiduel, adossés à la politique chaîne d'approvisionnement (REGLYZE-POL-SC-001). [NIS2 21.2.d.1]

La politique chaîne d'approvisionnement exige des clauses contractuelles ; aucun contrat fournisseur exécuté avec clauses de sécurité/DPA n'est attesté. [NIS2 21.2.d.2]

Reglyze est elle-même prestataire SaaS pour ses clients ; le modèle de responsabilité partagée et les engagements de service ne sont pas formellement documentés. [NIS2 21.2.d]

La détection repose sur les alertes WAF Cloudflare, les notifications Dependabot/Renovate et la surveillance d'astreinte ; pas de SIEM, mais couverture partielle documentée dans le PRI. [NIS2 21.2.b.2]

Un plan de réponse aux incidents (PRI v1.0) couvre classification, confinement, éradication et récupération ; jamais déclenché sur un incident réel ni exercé en simulation. [NIS2 21.2.b.1]

Aucun dispositif de préparation forensique (préservation de preuves, procédures d'investigation) formalisé ; la journalisation n'est que partiellement centralisée. [pas d'évidence directe]

Le PRI couvre l'éradication/récupération de façon générique ; aucune procédure spécifique de remédiation d'incident majeur/APT (reconstruction, chasse) n'est documentée. [NIS2 21.2.b.1]

La politique de test d'efficacité impose audits et tests ; AUCUN audit, revue indépendante ou test d'intrusion n'a jamais été conduit (NIS2 21.2.f.2 = 0). Écart le plus important. [NIS2 21.2.f.1, 21.2.f.2]

Le PCA (REGLYZE-BCP) traite la gestion d'urgence à haut niveau (RTO/RPO) ; aucun exercice de crise ni test de bascule n'a été conduit, astreinte concentrée sur une personne. [NIS2 21.2.c.4]

Les outils bureautiques sont des SaaS standard avec MFA ; aucune configuration de référence (durcissement macros, etc.) formalisée. [pas d'évidence directe]

Les navigateurs des postes sont à jour et adossés à la MFA ; aucune politique de configuration/durcissement navigateur gérée. [pas d'évidence directe]

L'application web est protégée par TLS + WAF Cloudflare, RBAC applicatif, correctif SSRF (S2) et CSP (S5) ; aucun test d'intrusion ni standard de sécurité applicative documenté. [NIS2 21.2.e]

Le reverse-proxy Traefik derrière Cloudflare impose HTTPS/HSTS (FORCE TLS) ; durcissement du serveur web réel mais non documenté ni audité. [NIS2 21.2.h.3, 21.2.e]

Postgres avec chiffrement au repos et isolation tenant par RLS (réelle et récente) ; pas de durcissement DB documenté ni de revue/audit base de données. [NIS2 21.2.h.2, 21.2.i.2]

L'e-mail transactionnel est délégué à Resend (fournisseur évalué, criticité medium, sans certification publique attestée) sur TLS ; aucune politique de messagerie formalisée. [NIS2 21.2.d.1]

Les logiciels/dépendances tiers sont suivis en continu par Dependabot/Renovate (veille + correctifs) ; pas de procédure formelle d'acquisition/homologation logicielle documentée. [NIS2 21.2.e.3]

Le développement sur mesure (le produit) s'appuie sur revue de PR, CI/CD et Dependabot ; aucun standard de codage sécurisé documenté ni SDLC formel. [NIS2 21.2.e.1]

L'hôte serveur unique (Hetzner Linux, Francfort) bénéficie du chiffrement au repos et d'un pare-feu ; aucun référentiel de durcissement serveur documenté. [NIS2 21.2.e]

Le serveur Linux est maintenu par les mises à jour OS et l'accès administrateur est protégé par MFA ; le durcissement Linux (CIS/BSI) n'est pas documenté. [NIS2 21.2.e]

Conteneurisation Docker avec images minimales (réel) et déploiement reproductible ; aucune politique de sécurité des conteneurs (scan d'images, secrets) formalisée. [NIS2 21.2.e.5]

Les postes clients sont adossés à la MFA et au chiffrement de disque mais aucun MDM ni configuration de référence gérée n'est en place. [NIS2 21.2.i]

Les ordinateurs portables de l'équipe distante utilisent chiffrement de disque et MFA ; aucune gestion centralisée (MDM), inventaire ou politique de poste formalisée. [NIS2 21.2.i]

Instance unique sans segmentation réseau multi-niveaux ; l'isolation tenant est assurée en base par RLS, mais l'architecture réseau reste plate et non formellement conçue. [NIS2 21.2.e]

Le réseau est géré via Cloudflare et Traefik sur un hôte unique ; pas de processus de gestion réseau formalisé (peu de surface propre en cloud). [NIS2 21.2.e]

Le filtrage combine WAF Cloudflare, reverse-proxy Traefik et pare-feu Hetzner, avec blocage egress ajouté (correctif SSRF S2) ; règles non formellement documentées. [NIS2 21.2.e]

L'accès distant d'administration passe par Cloudflare Tunnel/SSH chiffrés avec MFA imposée (tenant lieu de VPN) ; configuration non formellement documentée. [NIS2 21.2.j.1, 21.2.e]

Équipe entièrement en télétravail ; le poste à domicile est traité de façon informelle par la politique RH, sans guide de sécurité du poste à domicile dédié. [NIS2 21.2.i]

Le travail nomade s'appuie sur chiffrement de disque et MFA ; aucune politique de poste de travail mobile (écrans de confidentialité, réseaux non fiables) formalisée. [NIS2 21.2.i]