Reglyze is built on Reglyze

The information security policy and board briefing deck show CEO approval of risk-management measures; formal board-level approval resolution is implied but no separate signed approval record is evidenced beyond the policy sign-off field.

Active oversight is limited to a single director who is also the sole operator; the board briefing deck describes oversight intent but no recurring oversight meeting minutes or tracking artefacts are evidenced, making this ad hoc in practice.

The board briefing deck explicitly flags Article 20 personal liability for management body members; Cyril's acknowledgement is implicit in policy approval but no signed liability acknowledgement form is evidenced.

Policies state annual review cycles but no evidence of a completed review cycle exists yet (all documents are version 1.0 at initial issue); governance review cadence is planned but not yet operationally demonstrated.

The training plan documents a mandatory cybersecurity training programme for the management body and Cyril is noted as self-trained per task 1.5; however, no auditable completion records or refresher cadence evidence exists yet, capping implementation at 2.

The cybersecurity training plan establishes a mandatory programme for the management body; Cyril's self-training is noted but no formal enrolment or completion certificate is evidenced.

The training plan specifies an annual refresher cadence; no evidence of a completed first refresher cycle exists given all policies are at initial version 1.0.

No auditable completion records (certificates, LMS logs, sign-off sheets) are evidenced in the policy digest; the training plan describes the requirement but does not demonstrate fulfilment.

The management body consists solely of Cyril Poder; the training plan covers him, so coverage of all management body members is technically complete, though the single-person scope limits the robustness of this control.

The training plan explicitly encourages staff cybersecurity training for all 5 FTE; implementation is plausible given the small team but no training completion records are evidenced.

A comprehensive information security policy (REGLYZE-ISP-001) exists with a risk assessment framework, treatment plan, and review schedule; all documents are version 1.0 at initial issue with no evidence of a completed annual review cycle, capping documentation at 2.

The information security policy defines a risk assessment framework including methodology, scope, and asset classification; no evidence of a completed risk assessment register or risk treatment output is provided in the digest.

REGLYZE-ISP-001 is a written, version-controlled information security policy approved by the CEO; it is version 1.0 with next review 2026, so not yet confirmed reviewed within 12 months.

The information security policy references a risk treatment plan but no standalone risk treatment plan document or register is evidenced in the policy digest; treatment is described in principle only.

Risk acceptance criteria are referenced within the ISP framework section but no explicit documented risk acceptance criteria table or threshold definition is evidenced as a standalone artefact.

The ISP mandates annual risk review; no completed review cycle is evidenced (version 1.0, next review 2026), so the process is planned but not yet operationally demonstrated, capping implementation at 1.

A formal incident response plan exists (version 1.0) covering classification, detection, notification timelines, and post-incident review; however, the plan has never been triggered by a real incident and no tabletop or live test is evidenced, capping implementation at 2.

Cyril Poder as sole director has approved policies and the board briefing deck evidences governance oversight; however, as a 5-person org with a single director, formal periodic governance review cadence and escalation paths are nascent and untested. Policies are version 1.0 and not yet confirmed reviewed within 12 months by an independent body.

The incident response plan includes an incident classification and triage framework with severity levels; classification has not been exercised against a real event.

The IRP documents NIS2 Article 23 notification timelines (early warning 24h, notification 72h, final report 1 month); no actual notification to ANSSI has been made, so the process is documented but untested operationally.

The IRP includes a post-incident review section; since no real incident has occurred, no post-incident review has ever been conducted, making this entirely theoretical at present.

A business continuity plan and a backup/disaster recovery policy both exist; daily rclone-to-Google-Drive backups are operational, but restore has never been tested in the past 12 months, capping implementation at 2.

The BCP document covers scope, governance, RTO/RPO objectives, and recovery procedures; it is version 1.0 and has not been exercised, so operational maturity is documented-but-untested.

The DR policy defines recovery procedures for Hetzner primary and Cloudflare CDN/DNS failover scenarios; no DR test or failover drill is evidenced, capping implementation at 2.

Crisis management is addressed within the BCP at a high level; with a 5-person fully remote team and single on-call, a dedicated crisis management capability is structurally limited and no crisis simulation has been conducted.

The BCP and DR policy both mandate annual testing and exercises; no test has been conducted (backups untested, BCP unexercised), so the testing programme exists on paper only.

A supply chain security policy (REGLYZE-POL-SC-001) exists covering supplier risk assessment, contractual requirements, and monitoring; no evidence of completed supplier questionnaires or audit outputs is provided, capping implementation at 2.

The supply chain security policy defines a supplier risk assessment framework; key suppliers (Anthropic, Stripe, Hetzner, Cloudflare, GitHub, Resend) are identifiable from the stack profile but no completed risk assessment records are evidenced.

The supply chain policy specifies contractual security requirements to be imposed on suppliers; no evidence of executed supplier contracts with security clauses or DPA addenda is provided in the digest.

Supplier monitoring is described in the policy but no recurring supplier review cadence, scorecard, or monitoring log is evidenced; at 5 persons this is likely informal at best.

Dependabot and Renovate are actively enabled on the TypeScript/Node.js monorepo, providing automated software supply chain dependency monitoring; the vulnerability management policy also covers software supply chain risk.

Coordinated risk assessments with suppliers or sector peers are not evidenced; at Reglyze's scale and OOS status, participation in coordinated assessments (e.g. ANSSI sector exercises) has not been described.

A vulnerability management policy exists and Dependabot/Renovate provide automated dependency hygiene; a secure development lifecycle is implied by the TypeScript monorepo and GitHub pipeline but not formally documented as an SDLC policy.

Development practices on the TypeScript/Node.js monorepo with GitHub CI/CD imply a repeatable build and review process; no formal written secure development lifecycle (SDLC) policy or secure coding standard is evidenced in the digest.

The supply chain and vulnerability management policies reference security in procurement; no procurement checklist or vendor security evaluation form is evidenced as an operational artefact.

Dependabot and Renovate provide automated vulnerability detection and patch management for dependencies; the vulnerability management policy (REG-SEC-POL-003) documents scanning, patching, and CVD procedures.

The vulnerability management policy includes a coordinated vulnerability disclosure (CVD) process section; no public security.txt, bug bounty programme, or CVD disclosure record is evidenced operationally.

GitHub-based CI/CD with pull-request workflows implies change management controls; no formal change and configuration management policy or change log is evidenced as a standalone written document.

An effectiveness testing policy (REG-POL-ETP-001) exists defining audit cadence, KPIs, and management review; no completed audit, penetration test, or KPI measurement cycle is evidenced, capping implementation at 1.

The effectiveness testing policy mandates periodic security audits with a quarterly checklist template (Annex A); no completed audit report or checklist output is evidenced.

The effectiveness testing policy references penetration testing as a planned measure; no penetration test has been conducted and no test report is evidenced; implementation is zero at this time.

Detection relies on Cloudflare WAF alerts, Dependabot/Renovate notifications, and on-call monitoring by Cyril; no SIEM or SOC is in place, but tooling provides partial automated detection coverage documented in the IRP.

Continuous improvement is described as a principle in the effectiveness testing policy and ISP; no improvement log, corrective action register, or PDCA cycle evidence is provided.

A cybersecurity training plan exists covering awareness, role-based training, and hygiene baseline for all 5 staff; no training completion records or effectiveness measurement outputs are evidenced, capping implementation at 2.

The training plan establishes a cybersecurity awareness programme for all personnel; no completion records or awareness campaign artefacts (e.g. phishing simulation results) are evidenced.

Management body training is covered in both the training plan and the board briefing deck; Cyril's self-training is noted but no completion certificate or formal record exists.

The training plan specifies role-based security training; with only 5 staff and no dedicated security or development roles differentiated in the digest, role-based differentiation is limited in practice.

MFA enforced everywhere, encryption at rest and in transit, Dependabot/Renovate, and Cloudflare WAF constitute a strong cyber hygiene baseline operationally; the training plan and ISP document these as baseline requirements.

The training plan describes training effectiveness measurement requirements; no measurement data, quiz results, or effectiveness assessment outputs are evidenced as having been produced.

A cryptography and encryption policy (REG-SEC-POL-CRYPTO-001) exists; encryption at rest and in transit is operationally enforced (Cloudflare TLS, Hetzner storage encryption); key management procedures are documented but not independently audited.

REG-SEC-POL-CRYPTO-001 defines cryptographic standards, approved algorithms, and usage requirements; it is version 1.0 and not yet confirmed reviewed within 12 months.

Encryption at rest is operationally enforced across Postgres, Redis, MinIO on Hetzner and Google Drive backups; this is a genuine operational strength. Documentation exists in the cryptography policy but not yet through a completed annual review.

TLS is enforced via Cloudflare for all in-transit communications; this is fully implemented and covers all in-scope assets. Documentation exists in the cryptography policy at version 1.0.

Key management procedures are described in the cryptography policy; operational key management relies on platform-managed keys (Cloudflare, Hetzner, Google) which is appropriate at this scale but no independent key management audit is evidenced.

Cryptographic agility (ability to migrate algorithms) is not explicitly addressed as an operational capability; the cryptography policy does not evidence a tested algorithm migration plan or agility assessment.

The asset management policy (REGLYZE-POL-ASM-001) defines asset inventory and classification requirements; the tech stack (Hetzner, Cloudflare, GitHub, Postgres, Redis, MinIO, etc.) is identifiable but no completed asset register is evidenced as an operational artefact.

The access control policy (REG-SEC-POL-001) documents least-privilege, need-to-know, and role-based access principles; MFA is enforced everywhere, providing strong operational backing.

MFA is enforced across all systems; identity and access management relies on platform-native controls (GitHub, Hetzner, Cloudflare) with no centralised IAM platform, which is proportionate for 5 persons but limits maturity.

The HR security policy covers pre-employment screening and onboarding security requirements; no completed onboarding checklist, background check record, or NDA execution log is evidenced for the current 5-person team.

The HR security policy addresses termination and role-change procedures including access revocation; no offboarding checklist completion record or access revocation log is evidenced operationally.

MFA is enforced everywhere per the profile and documented in the MFA/secured communications policy (REGLYZE-POL-SEC-007); secured communications rely on standard SaaS tooling (not end-to-end encrypted dedicated platforms) and no secured emergency communication system is evidenced.

MFA is enforced everywhere across all systems and accounts; this is a genuine operational strength fully covering all in-scope assets. The MFA policy documents this requirement at version 1.0.

Continuous authentication (beyond MFA at login) is not described as an operational capability; no session risk scoring, device trust, or continuous authentication tooling is evidenced.

The MFA/secured communications policy references requirements for secured voice and video communications; no dedicated end-to-end encrypted voice/video platform (beyond standard commercial tools) is evidenced as operationally deployed.

The effectiveness testing policy defines KPI thresholds and an escalation matrix (Annex B); no KPI measurement data or dashboard output is evidenced as having been produced.

Secured emergency communications are addressed in the MFA/secured communications policy; no dedicated emergency communication channel, out-of-band contact list, or emergency comms test is evidenced operationally.

With a single-person management body, a formal escalation path to the management body is structurally trivial but not documented as a distinct procedure; no escalation matrix or on-call escalation chain to a board level is evidenced beyond the incident response plan's internal escalation.

The incident response plan is a documented, structured procedure covering containment, eradication, and recovery; it has never been activated in a real incident, so operational maturity is repeatable-on-paper but untested.

Daily rclone backups to Google Drive are operationally running; the backup/DR policy (REGLYZE-POL-BDR-001) documents retention and recovery objectives, but restore testing has not been performed in the past 12 months.

The effectiveness testing policy mandates management body review of audit outputs; no completed management review meeting record or remediation backlog review is evidenced.

HR security, access control, and asset management policies all exist as separate written documents; MFA is enforced everywhere and least-privilege access is described; no evidence of completed onboarding/offboarding checklists or asset inventory register as operational artefacts.

Text communications likely use standard encrypted messaging (e.g. Signal or equivalent) consistent with a remote-first tech team; the policy documents secured text communication requirements, though no specific tool mandate or enforcement evidence is provided.