We voluntarily implement the risk-management measures using Reglyze (the product) as both subject and tool. This is dogfooding, not a regulatory obligation. We publish it so you can verify what an AI-built evidence base actually looks like before you buy.
We use our own platform to manage Reglyze's compliance posture — in each country's native framework, not raw NIS2. Same scoring, same policies, same controls our customers use. No marketing fluff, just our actual numbers.
Last self-assessed: 19 May 2026
under 1 hour
to document our whole evidence base (vs 80–120h manual)
100%
critical-patch SLA (Dependabot + Renovate, 3 real fixes)
Quarterly
self-audit cadence — last cycle Q2-2026
Name
Reglyze
Country
FR
Sector
digital_providers
Headcount
5
NIS2 Status
La politique de gestion des actifs (REGLYZE-POL-ASM-001) définit l'inventaire des systèmes ; le stack de production est identifiable (Hetzner, Cloudflare, GitHub, Postgres, Redis, MinIO) mais aucun registre formellement complété n'est produit comme artefact. [NIS2 21.2.i.1]
La PSSI (REGLYZE-ISP-001) définit un cadre de gestion des risques (méthodologie, périmètre, traitement) ; aucun registre de risques complété n'est encore attesté (documents v1.0). [NIS2 21.2.a.1]
L'organisation sécurité et les rôles sont décrits dans l'ISP et le board briefing deck, approuvés par Cyril Poder, dirigeant unique. [NIS2 20.1.a]
Les rôles sont décrits dans les politiques ; avec 5 personnes et un dirigeant unique, aucun registre nominatif formel des porteurs de rôles n'est maintenu comme artefact. [NIS2 20.1.a]
Reglyze étant hors périmètre/volontaire, aucun point de contact ni référent CSIRT/PSNC n'est désigné ni enregistré auprès de l'ACN. [pas d'évidence directe]
Les politiques prévoient une revue des rôles ; aucun cycle de réexamen complété (documents en v1.0). [NIS2 20.1.a.4]
La politique RH (hr_security) couvre le contrôle préalable du personnel accédant aux SI ; aucun enregistrement de screening/vérification complété pour les 5 collaborateurs. [NIS2 21.2.i.4]
La politique RH couvre la sélection des administrateurs système ; dirigeant unique cumulant les rôles d'administration, aucune évaluation formalisée archivée. [NIS2 21.2.i.4]
La politique RH documente les procédures de fiabilité des ressources humaines. [NIS2 21.2.i]
FORCE documentaire : 14 politiques v1.0 couvrent la quasi-totalité des domaines requis (ISP, gestion du risque, RH, chaîne d'appro., actifs, vulnérabilités, PCA/PRA, contrôle d'accès, chiffrement, formation, MFA/comms). [NIS2 21.2.a.2]
Les politiques existantes couvrent les exigences des domaines listés ; aucune cartographie formelle des exigences par table complétée. [NIS2 21.2.a.2]
L'ensemble des politiques est approuvé par le dirigeant unique (champ d'approbation renseigné dans chaque document). [NIS2 20.1.a]
Toutes les politiques prévoient une revue annuelle ; aucune revue effectuée à ce jour (v1.0, prochaine revue 2026). [NIS2 21.2.a.5]
L'auto-évaluation NIS2 de mai 2026 constitue une vérification de conformité (dogfooding du produit) ; l'exercice Misure ACN est en cours. [NIS2 21.2.f]
La politique chaîne d'approvisionnement (REGLYZE-POL-SC-001) exige l'intégration d'exigences de sécurité dans les approvisionnements ; aucune fourniture avec exigences contractuellement exécutées n'est attestée. [NIS2 21.2.d.2]
La politique chaîne d'appro. prévoit l'attribution de rôles sécurité aux tiers ; aucune attribution formelle documentée pour les 7 fournisseurs. [NIS2 21.2.d]
Aucun personnel de tiers n'est inscrit dans un registre nominatif de porteurs de rôles. [pas d'évidence directe]
7 fournisseurs inventoriés et évalués (Hetzner, Cloudflare, Anthropic, Stripe, GitHub, Resend, Google) avec type de fourniture ; référents contact non systématiquement formalisés. [NIS2 21.2.d.1]
La politique exige des clauses de sécurité dans les contrats ; aucun contrat fournisseur exécuté avec clauses de sécurité/DPA n'est attesté. [NIS2 21.2.d.2]
Le risque associé aux fournitures est évalué et documenté : criticité classée (critical/high/medium) et score de risque résiduel par fournisseur pour les 7 fournisseurs. [NIS2 21.2.d.1]
La politique prévoit une vérification périodique de conformité des fournitures ; aucune cadence de revue périodique des tiers n'est attestée. [NIS2 21.2.d.3]
La politique d'actifs définit l'inventaire matériel ; infra 100% cloud sans matériel détenu (hors postes distants), aucun inventaire hardware formel complété. [NIS2 21.2.i.1]
Le stack applicatif et les services sont identifiables ; SBOM de fait via Dependabot/Renovate sur le monorepo ; pas de registre formel complété. [NIS2 21.2.i.1]
Les services cloud/fournisseurs sont inventoriés dans l'évaluation chaîne d'approvisionnement (7 fournisseurs). [NIS2 21.2.d.1]
FORCE : identification continue des vulnérabilités via Dependabot + Renovate + GitHub advisories sur l'ensemble du monorepo. [NIS2 21.2.e.3]
La PSSI définit une méthodologie d'analyse des risques ; aucune évaluation de risque formellement exécutée et documentée (identification/analyse/pondération) n'est attestée. [NIS2 21.2.a.1]
La politique prévoit une revue périodique du risque ; aucun cycle d'évaluation complété (v1.0). [NIS2 21.2.a.5]
L'approbation par les organes dirigeants est prévue ; aucune évaluation de risque complétée à approuver à ce jour. [NIS2 20.1.a]
Le plan de traitement des risques est référencé dans l'ISP mais aucun plan de traitement autonome (options, priorités, rôles, échéances, risque résiduel) n'est produit comme artefact. [NIS2 21.2.a.3]
Aucune analyse formalisée des mesures compensatoires ni du risque résiduel associé n'est documentée. [NIS2 21.2.a.3]
L'approbation du plan de traitement par les organes dirigeants est prévue ; aucun plan formel à approuver. [NIS2 20.1.a]
Les canaux GitHub advisories/Dependabot sont surveillés en continu, mais les canaux du CSIRT Italia et des ISAC sectoriels ne sont pas monitorés (statut volontaire). [pas d'évidence directe]
FORCE : résolution rapide des vulnérabilités via correctifs automatiques Dependabot/Renovate — 3 PR de sécurité réelles appliquées, SLA de patch 100%. [NIS2 21.2.e.3]
La politique de gestion des vulnérabilités (REG-SEC-POL-003) définit identification, monitoring, priorisation, rôles et responsabilités. [NIS2 21.2.e]
La politique de gestion des vulnérabilités est approuvée par le dirigeant unique. [NIS2 20.1.a]
Les écarts sont identifiés par l'auto-évaluation NIS2 ; un plan d'adéquation formel approuvé, corrélé au réexamen des politiques, n'est pas encore établi. [NIS2 21.2.f.4]
Le board briefing deck matérialise l'information des dirigeants ; aucune cadence de relations périodiques attestée. [NIS2 21.2.f.4]
Un plan de continuité opérationnelle (REGLYZE-POL-BCP) v1.0 couvre finalités, rôles, activation et ressources (dont backups) ; non exercé. [NIS2 21.2.c.1]
Un plan de reprise après sinistre (REGLYZE-POL-BDR-001) définit les procédures et objectifs de ripristino (Hetzner primaire, bascule Cloudflare) ; aucun exercice DR réalisé. [NIS2 21.2.c.3]
La gestion de crise est abordée à haut niveau dans le PCA ; équipe de 5 personnes en astreinte unique (Cyril), aucun dispositif de gestion de crise autonome exercé. [NIS2 21.2.c.4]
Les plans PCA/PRA sont approuvés par le dirigeant unique. [NIS2 20.1.a]
Les plans prévoient une revue périodique ; aucun cycle de réexamen ni exercice complété (restauration non testée sur 12 mois). [NIS2 21.2.c.5]
Comptes nominatifs sur l'ensemble des plateformes (GitHub, Hetzner, Cloudflare) et Better Auth pour les utilisateurs applicatifs ; comptes d'accès distant individuels. [NIS2 21.2.i.2]
Règles de robustesse des mots de passe via Better Auth ; identifiants hachés ; renforcés par la MFA. [NIS2 21.2.j]
La politique de contrôle d'accès impose une revue périodique des utenze/autorisations ; aucun cycle de revue des accès complété ni journal de révocation attesté. [NIS2 21.2.i.5]
La politique de contrôle d'accès (REG-SEC-POL-001) documente les procédures de gestion des utenze. [NIS2 21.2.i.2]
Les modalités d'authentification sont commensurées au risque (privilèges, criticité, type d'opérations) ; MFA généralisée par défaut. [NIS2 21.2.j]
FORCE : authentification multifactorielle imposée partout (SSH, GitHub, Hetzner, Cloudflare, application). [NIS2 21.2.j.1]
La politique MFA/comms sécurisées (REGLYZE-POL-SEC-007) documente les procédures d'authentification. [NIS2 21.2.j]
Moindre privilège et besoin d'en connaître documentés dans la politique ; RBAC applicatif + rôles DB RLS (reglyze_app/reglyze_admin). [NIS2 21.2.i.2]
Distinction des comptes à privilèges via le split de rôles RLS reglyze_admin (bypass) vs reglyze_app (scoped) et comptes d'administration séparés sur les plateformes. [NIS2 21.2.i.2]
La politique de contrôle d'accès documente les règles de moindre privilège et de séparation des fonctions. [NIS2 21.2.i.2]
Aucun local serveur détenu ; sécurité physique héritée du datacenter Hetzner (ISO 27001, Francfort), équipe entièrement distante. Contrôle hérité documenté dans l'évaluation chaîne d'appro. [NIS2 21.2.d]
Sans locaux techniques propres, les procédures d'accès physique sont celles de Hetzner ; non formalisées côté Reglyze. [NIS2 21.2.d]
Un plan de formation sécurité v1.0 couvre l'ensemble des 5 collaborateurs et les organes dirigeants, avec contenus et modalités de vérification. [NIS2 21.2.g.1]
Le plan de formation est approuvé par le dirigeant unique (également couvert par le board briefing deck). [NIS2 20.2.a]
Aucun registre de complétion de la formation ni enregistrement des vérifications n'est produit à ce jour. [NIS2 21.2.g]
La politique de chiffrement (REG-SEC-POL-CRYPTO-001) impose le chiffrement ; chiffrement au repos opérationnellement fort côté serveurs/backups, mais le chiffrement des postes/supports portables n'est pas formellement attesté par device. [NIS2 21.2.h.2]
Infra cloud entièrement distante, aucun support amovible en production ; désactivation de l'auto-exécution et scan des supports non formalisés (faible pertinence opérationnelle). [NIS2 21.2.e]
La politique de chiffrement couvre le chiffrement des données ; les procédures spécifiques aux supports amovibles/postes ne sont pas détaillées. [NIS2 21.2.h.1]
FORCE : chiffrement des données en transit imposé partout via TLS Cloudflare (suites modernes, HSTS). [NIS2 21.2.h.3]
La politique de chiffrement documente les protocoles de transmission sécurisée. [NIS2 21.2.h.1]
Sauvegardes quotidiennes rclone -> Google Drive opérationnelles (FORCE) et chiffrées au repos ; pas de véritable copie hors-ligne/immuable pour les SI rilevanti. [NIS2 21.2.c.2]
La politique de sauvegarde/PRA (REGLYZE-POL-BDR-001) documente les procédures de backup et les objectifs de rétention. [NIS2 21.2.c.2]
Renovate maintient les composants sur des versions supportées ; l'exigence de n'installer que du logiciel bénéficiant de correctifs n'est pas formellement documentée. [NIS2 21.2.e]
FORCE : installation sans retard injustifié des derniers correctifs via Dependabot/Renovate — 3 PR de sécurité réelles appliquées, SLA 100%. [NIS2 21.2.e.3]
La politique de gestion des vulnérabilités documente les procédures de mise à jour. [NIS2 21.2.e]
Les accès distants et à privilèges sont journalisés (logs GitHub, logs de déploiement, logs SSH/DB). [NIS2 21.2.e.5]
Les logs nécessaires au monitoring sont acquis ; centralisation partielle via log-shipper. [NIS2 21.2.e.5]
Aucune durée de conservation des logs formellement définie et documentée en fonction du risque. [NIS2 21.2.e.5]
Les procédures de journalisation sont partiellement couvertes par les politiques ; pas de procédure dédiée complète attestée. [NIS2 21.2.e.5]
Développement sur monorepo TypeScript avec CI/CD GitHub et revues de PR (pratiques implicites de développement sécurisé) ; aucune politique SDLC/codage sécurisé formalisée. [NIS2 21.2.e.1]
Accès distant d'administration via Cloudflare Tunnel + SSH (chiffré) avec MFA imposée ; mesures de sécurité en place. [NIS2 21.2.e]
Aucun élenco formel des systèmes accessibles à distance et de leurs modalités n'est maintenu. [NIS2 21.2.e]
Systèmes périmétriques en place : Cloudflare WAF + reverse-proxy Traefik ; blocage egress ajouté (correctif SSRF S2). [NIS2 21.2.e]
Les procédures relatives aux accès distants et aux systèmes périmétriques sont partiellement couvertes par les politiques, sans procédure dédiée complète. [NIS2 21.2.e]
Outils de détection en place : alertes Cloudflare WAF + Dependabot/Renovate, monitoring en astreinte par Cyril ; pas de SIEM/SOC. [NIS2 21.2.b.2]
Aucun niveau de service (SL) formellement défini et documenté aux fins de détection d'incidents. [pas d'évidence directe]
Le PRI couvre la détection et la qualification des événements ; alertes Cloudflare/Dependabot en entrée ; non testé. [NIS2 21.2.b]
Pas d'AV/EDR sur endpoints (infra conteneurisée immuable) ; le WAF Cloudflare filtre les menaces web mais aucun système de protection endpoint anti-malware n'est déployé. [NIS2 21.2.e]
Aucun programme anti-malware endpoint documenté. [NIS2 21.2.e]
Un plan de réponse aux incidents (PRI) v1.0 couvre phases, rôles, notification au CSIRT (délais alerte précoce/notification/rapport final), contacts et reporting ; jamais déclenché sur un incident réel. [NIS2 21.2.b.4]
Le plan de réponse aux incidents est approuvé par le dirigeant unique. [NIS2 20.1.a]
Le PRI prévoit un réexamen périodique et l'intégration des leçons apprises ; jamais exercé ni révisé (aucun incident réel, pas d'exercice sur table). [NIS2 21.2.b.5]
Le PRI référence la communication aux destinataires des services ; procédure jamais exercée et liste des contacts externes partielle. [NIS2 21.2.b.4]
Aucune procédure documentée d'information du public sur les incidents (sur injonction de l'ACN) n'est attestée. [pas d'évidence directe]
Le PRI et la politique de sauvegarde/PRA couvrent les procédures de ripristino du fonctionnement normal ; sauvegardes quotidiennes opérationnelles mais restauration non testée sur 12 mois. [NIS2 21.2.c.2]
Hetzner Online GmbH
Cloud infrastructure / hosting
Data shared: All application data, customer accounts, encrypted backups
Cloudflare
CDN, DNS, WAF, TLS termination
Data shared: All HTTP/S traffic metadata, no plaintext payloads
Anthropic
AI/LLM (Claude API for document generation)
Data shared: Customer organization context for document generation prompts
GitHub
Source code hosting and CI/CD
Data shared: Source code, deployment secrets via Actions
Resend
Transactional email delivery
Data shared: Recipient email addresses (customer admins, vendor questionnaire contacts), email bodies (compliance notifications, vendor questionnaire requests, billing notices).
Google (Workspace + Drive via rclone)
Off-site backup destination
Data shared: Encrypted daily Postgres dumps + MinIO blob backups mirrored via rclone. Encryption at rest by Google; Reglyze does not currently apply client-side encryption on top.
Stripe
Payment processing and billing
Data shared: Customer billing details, subscription metadata
NIS2 Article 20(2) Training Certificate — Cyril Poder
Updated 17 May 2026
Reglyze Information Security Policy
Updated 17 May 2026
Reglyze Incident Response Plan
Updated 17 May 2026
Reglyze Business Continuity Plan
Updated 17 May 2026
Reglyze Backup and Disaster Recovery Plan
Updated 17 May 2026
Reglyze Supply Chain Security Policy
Updated 17 May 2026
Reglyze Vulnerability Management Policy
Updated 17 May 2026
Reglyze Effectiveness Testing Policy
Updated 17 May 2026
Reglyze Cybersecurity Training Plan
Updated 17 May 2026
Reglyze Cryptography Policy
Updated 17 May 2026
Reglyze HR Security Policy
Updated 17 May 2026
Reglyze Access Control Policy
Updated 17 May 2026
Reglyze Asset Management Policy
Updated 17 May 2026
MFA & Secured Communications Policy
Updated 17 May 2026
Board/Management Cybersecurity Briefing Deck
Updated 17 May 2026
Most compliance vendors talk about security but never show their own posture. We think that's backwards. If our platform is good enough for our customers, it's good enough for us.
Every score, control, supplier, and policy on this page comes from the same Reglyze platform we sell — rendered in each country's native framework, the way a French, Italian or German buyer actually assesses. There's no separate trust portal, no manually-curated security PDF.
You can verify it yourself: api.reglyze.com/api/public/trust/reglyze