6.4 Notification and Rule Engine
The notification and rule engine is what turns a cryptographic inventory into operational work: it evaluates rules over findings and raises cases in the destinations configured for them.
6.4.1 Concept
A cryptographic inventory that is only a dashboard requires somebody to look at it. The notification engine closes that loop: a rule watches for a condition, and when the condition is met the engine opens a case and delivers it to a destination — a ticket, a message, an email. The finding then has an owner and a state, rather than a position in a list.
6.4.2 Rules
A rule is the central object. It defines the trigger condition, the scope it applies to, the destination, and the escalation and reminder behaviour.
Triggers are drawn from a catalogue of events and metrics — certificate approaching expiry, certificate expired, policy failure, newly discovered material of a given criticality, key reuse detected, material resolved, scan failed.
Scope is expressed with the same filters as the dashboards, including the tag expression language, so a rule can be as narrow as one tagged subset of the estate.
Rules are managed by administrators, and access is role-gated.
6.4.3 Cases and Destinations
A rule match opens a case in the platform. The case is the platform-side record of the finding needing attention, and it holds the state.
A case is delivered to one or more destinations. Destinations include service management tools such as ServiceNow, messaging platforms, and email.
Where a destination supports it, the case state and the destination record state are synchronised, so closing the ticket closes the case.
A case can be held, deferred or closed in the platform independently, for findings that are accepted risk rather than work.
6.4.4 Storm Control and Idempotency
This section matters more than its length suggests. A cryptographic finding engine over a large estate can generate an enormous number of matches from a single scan — a newly-applied policy can fail thousands of materials at once — and an engine without these controls will flood a service management queue on its first run and be switched off.
-
Idempotency: a rule that matches the same finding repeatedly produces one case, not one per evaluation.
-
Storm control: a burst of matches is rate-limited or aggregated rather than delivered individually.
-
Failure semantics: a destination that is unavailable does not lose the case. Delivery is retried and the case persists.
Reminders and escalation fire on elapsed time rather than on re-match, so an open case escalates without generating new cases.
6.4.5 Scheduler and Synchronisation
A scheduler runs rule evaluation on an interval.
A separate closure sweep handles reminders, escalation steps, expiry-mode closes and stale held cases. It is separate because it fires on elapsed time, not on a match.
An inbound synchronisation pass polls each active destination for state changes on records the engine created.
The three intervals together determine how quickly a finding becomes a ticket and how quickly a closed ticket clears, so record the configured values.