Connecteur · ServiceNow
Un événement d’encadrement devient un ticket.
Prévu · aucune date fixée
Les équipes risques et exploitation travaillent dans ServiceNow, et un événement qui n’y devient pas un enregistrement n’est pas traité. Le connecteur prévu ferait correspondre votre inventaire d’agents à la CMDB, écrirait les événements d’encadrement et les reçus dans les enregistrements d’audit GRC et les lierait aux tickets ITSM. Un énoncé refusé ou une numérotation bloquée auraient alors un autre endroit où aller qu’un tableau de bord.
Ce que le connecteur écrirait
{
"table": "sn_grc_audit_record",
"source": "audact",
"ci_ref": "cmdb_ci:audact_agent_dental_intake_v2",
"event": "governance_gate_blocked",
"policy": "commercial_commitment",
"severity": "hard",
"receipt_id": "rcpt_gov_01HX7...",
"incident": { "create": true, "assignment_group": "AI Risk" }
}Exemple chiffré. Acme GmbH, Nova Industries et Kestrel Industries sont fictifs ; aucune donnée client n’apparaît ici.
Le bloc incident serait facultatif et défini par type d’événement. Tous les refus ne méritent pas un ticket ; ceux qui en méritent un ne devraient pas dépendre de quelqu’un qui surveille un écran.
Ce que le connecteur porterait
- Inventaire d’agents issu de la CMDB ServiceNow.
- Prévu
- Événements d’encadrement et reçus dans les enregistrements d’audit GRC.
- Prévu
- Création de tickets ITSM par type d’événement, avec un groupe d’affectation.
- Prévu
- L’encadrement lui-même (information, porte de contrôle, éligibilité) ne dépend pas du connecteur ; il est En tests contrôlés (Allemagne : couche de règles nationale active. Pays-Bas : en développement. Belgique et Autriche : prévues.).
- En tests contrôlés
À qui il s’adresse
Là où le workflow est le contrôle.
Dans une grande organisation, un contrôle qui n’est pas un workflow n’est qu’une suggestion. C’est dans ServiceNow que vit le workflow, et un déploiement d’IA dont les exceptions atterrissent ailleurs sort discrètement de l’environnement de contrôle sur lequel tourne le reste de l’entreprise.
C’est tout l’argument en faveur de ce connecteur. Il n’ajouterait pas d’encadrement ; il placerait l’encadrement là où l’organisation attribue, escalade et clôt déjà.
Configuration
Cinq étapes, une fois le connecteur livré.
- Connecter Audact à ServiceNow avec un jeton d’API.
- Faire correspondre vos éléments de configuration CMDB à l’inventaire d’agents Audact.
- Configurer les packs de règles par juridiction dans le moteur de politique Audact.
- Activer l’export des preuves vers les enregistrements d’audit GRC.
- Passer en actif. Les événements alimentent les workflows au moment où ils se produisent.
Questions
- Est-ce dans le ServiceNow Store ?
- Pas encore. Une fiche est prévue et cette page l’indiquera lorsqu’elle existera.
- Chaque événement d’encadrement créerait-il un ticket ?
- Seulement les types que vous choisissez. Les autres arriveraient comme enregistrements d’audit, ce qui est leur place pour la plupart — un ticket par refus habitue les gens à clore des tickets sans les lire.
Les mêmes primitives, sans le connecteur
Un connecteur serait un chemin plus court vers une plateforme. En dessous, il y aurait l’API REST Audact, exécutée dans la plateforme gérée, et dans les deux cas la même chaîne de preuves.
Pages associées
Tous les connecteurs OneTrust Les mêmes événements, côté confidentialité.
Observability Layer Le même flux, en natif.
L’API Six capacités, une seule API, au sein de la plateforme gérée.