Intégration de la gestion des exceptions

[Ouafa-FERGE]

Bonjour,

Est-ce possible d'intégrer la gestion des exceptions dans Deming?

De la même façon que les plans d'action, il sera intéressant d'avoir un formulaire expliquant l'exception avec la possibilité de le lier au contrôle "Non Conforme".
Cette exception suivra un workflow de validation par l'organe supérieur (DG par ex)

Les exceptions s'afficheront également dans le tableau de board.

Merci pour l'effort fournit
Ouafa

[dbarzin]

Feature Request: Gestion des exceptions à la politique de sécurité

Résumé

Proposer un module de gestion des exceptions à la politique de sécurité dans Deming, permettant de tracer formellement les non-conformités assumées avec un circuit d'approbation, une date d'expiration et des contrôles compensatoires associés.

---

Contexte et motivation

Dans la pratique d'un SMSI, il arrive régulièrement qu'une mesure de sécurité ne puisse pas être appliquée dans les délais requis, ou ne soit techniquement pas applicable à un périmètre donné (systèmes legacy, contraintes métier, coût disproportionné, etc.). Ces situations ne disparaissent pas en les ignorant — elles doivent au contraire être documentées, approuvées et suivies pour :

• éviter que des non-conformités restent dans l'angle mort du SMSI,
• démontrer à un auditeur que les écarts sont maîtrisés et encadrés,
• forcer une revue périodique via la date d'expiration,
• associer des contrôles compensatoires qui réduisent le risque résiduel pendant la période d'exception.

Aujourd'hui, ce suivi se fait souvent dans des feuilles de calcul ou des commentaires épars. Un objet dédié dans Deming permettrait de centraliser et formaliser ce processus, en cohérence avec les exigences d'ISO 27001 (chapitres 6.1 et 10) et NIS2.

---

Proposition : modèle de données

Un objet SecurityException avec les champs suivants :

Champ	Type	Description
name	string	Nom court et identifiant de l'exception
description	text	Description de la non-conformité constatée
status	enum	Statut courant de l'exception (voir ci-dessous)
severity	enum	low / medium / high / critical
expiry_date	date	Date d'expiration — passage automatique au statut expired
observation	text	Notes libres, justification métier, contexte complémentaire
owners	M2M → Actor	Un ou plusieurs responsables du suivi de l'exception
applied_controls	M2M → Measure	Mesures compensatoires actives pendant la période d'exception
measures	M2M → Measure	Mesures de sécurité concernées par la dérogation

Statuts

L'exception évolue à travers les statuts suivants :

• draft — en cours de rédaction par le responsable.
• submitted — soumise pour approbation formelle.
• approved — validée par l'approbateur (rôle dédié) ; seul l'approbateur peut passer à ce statut.
• rejected — refusée par l'approbateur, avec observation motivant le refus.
• expired — la date d'expiration est dépassée ; l'exception doit être renouvelée ou la non-conformité doit être levée.

---

Relations

• Une exception est liée à une ou plusieurs mesures de sécurité concernées par la dérogation.
• Elle peut être atténuée par des contrôles compensatoires (applied controls).
• Un ou plusieurs propriétaires (acteurs) sont responsables du suivi.
• Un approbateur unique valide formellement l'exception.

---

Interface suggérée

• Une entrée dédiée dans le menu latéral.
• Tableau avec filtres par statut, sévérité, date d'expiration proche.
• Alerte sur le tableau de bord pour les exceptions arrivant à expiration.
• Inclusion dans les rapports de pilotage SMSI : liste des exceptions actives avec statut, sévérité et date d'expiration.

---

Impact attendu

• Meilleure traçabilité des non-conformités connues et assumées.
• Préparation facilitée aux audits ISO 27001 (preuve de maîtrise des écarts).
• Réduction du suivi hors outil (feuilles de calcul).
• Conformité renforcée avec les exigences de documentation NIS2.

---

Feature Request: Security Policy Exception Management

Summary

Propose a module for managing security policy exceptions in Deming, allowing formal tracking of assumed non-compliances with an approval workflow, an expiry date, and associated compensating controls.

---

Context and motivation

In ISMS practice, it regularly happens that a security measure cannot be applied within the required timeframe, or is technically not applicable to a given scope (legacy systems, business constraints, disproportionate cost, etc.). These situations do not go away by ignoring them — they must instead be documented, approved, and tracked in order to:

• prevent non-compliances from remaining blind spots in the ISMS,
• demonstrate to an auditor that deviations are controlled and managed,
• enforce periodic review via the expiry date,
• associate compensating controls that reduce residual risk during the exception period.

Today, this tracking is often done in spreadsheets or scattered comments. A dedicated object in Deming would centralize and formalize this process, in line with the requirements of ISO 27001 (chapters 6.1 and 10) and NIS2.

---

Proposal: data model

A SecurityException object with the following fields:

Field	Type	Description
name	string	Short name and identifier of the exception
description	text	Description of the identified non-compliance
status	enum	Current status of the exception (see below)
severity	enum	low / medium / high / critical
expiry_date	date	Expiry date — automatic transition to expired status
observation	text	Free-form notes, business justification, additional context
owners	M2M → Actor	One or more actors responsible for following up the exception
applied_controls	M2M → Measure	Compensating controls active during the exception period
measures	M2M → Measure	Security measures affected by the exception

Statuses

The exception progresses through the following statuses:

• draft — being drafted by the responsible owner.
• submitted — submitted for formal approval.
• approved — validated by the approver (dedicated role); only the approver can set this status.
• rejected — refused by the approver, with an observation motivating the refusal.
• expired — the expiry date has passed; the exception must be renewed or the non-compliance must be remediated.

---

Relationships

• An exception is linked to one or more security measures affected by the deviation.
• It can be mitigated by compensating controls (applied controls).
• One or more owners (actors) are responsible for follow-up.
• A single approver formally validates the exception.

---

Suggested UI

• A dedicated entry in the sidebar menu.
• Table with filters by status, severity, upcoming expiry date.
• Dashboard alert for exceptions nearing expiry.
• Inclusion in ISMS management reports: list of active exceptions with status, severity, and expiry date.

---

Expected impact

• Better traceability of known and assumed non-compliances.
• Easier preparation for ISO 27001 audits (evidence of deviation management).
• Reduction of out-of-tool tracking (spreadsheets).
• Strengthened compliance with NIS2 documentation requirements.

---

@gorth-git @quentingosset @ggs67 @Ouafa-FERGE @c-jar @herewithme @charlesgoyard @yjacolin @lb-consult
Thank you for considering this proposal. I am available to discuss it further or contribute to the implementation if needed.