Étendez tout type de registre avec vos propres champs
Les métadonnées que votre schéma n'avait jamais prévues finissent hors du registre
Chaque programme de confidentialité et de sécurité collecte des métadonnées que le schéma standard n'avait jamais anticipées — un propriétaire d'actif interne, un code d'unité opérationnelle, une référence que votre auditeur attend sur chaque registre. Le schéma figé n'a pas de place pour cela.
Ces données atterrissent donc dans un tableur annexe, une note en texte libre ou la boîte de réception de quelqu'un — déconnectées du registre qu'elles décrivent et invisibles lors de l'export.
L'alternative est pire : une demande de modification adressée à l'ingénierie pour un seul champ, en attendant un cycle de mise en production pour saisir une information dont votre équipe avait besoin hier.
Ce que vous pouvez faire avec les champs personnalisés
- Définissez des modèles de champs personnalisés par type d'entité directement dans les paramètres généraux.
- Affichez ces champs sur les pages de détail des entités de manière dynamique — sans modification de code, sans mise en production.
- Conservez les valeurs personnalisées dans le registre lui-même, stockées dans le document sous-jacent, et non dans un système annexe.
- Maintenez un schéma cohérent unique par entreprise grâce à un document de paramètres unique, afin que les définitions ne puissent ni entrer en conflit ni dériver.
- Saisissez les données personnalisées aux côtés des attributs standard pour qu'elles accompagnent le registre lors de l'export.
Ce que cela apporte à votre programme
- Saisissez les métadonnées propres à votre organisation sur les registres qui comptent — au lieu de les laisser se disperser dans des tableurs qui se périment.
- Évitez la file d'attente de l'ingénierie pour les modifications de schéma courantes ; un administrateur ajoute un champ dans les paramètres plutôt que d'ouvrir un ticket pour un développeur.
- Conservez les attributs supplémentaires au même endroit pour tous les types de registres, afin que chaque propriétaire, code ou référence vive sur le registre — et non à côté.
- Exportez des registres complets réunissant champs personnalisés et champs standard, afin que rien n'ait à être rapproché à la main avant un audit.
Conçu pour la conformité
Les champs personnalisés sont administrés comme de la configuration, et non comme du code — c'est ce qui les maintient contrôlés et cohérents dans toute votre entreprise.
| Ce que fait le DPMS | Correspond à | Comment |
|---|---|---|
| Centralise les définitions de champs par type d'entité | Gouvernance de la configuration | Modèles configurés dans les paramètres généraux, appliqués partout où cette entité est affichée |
| Évite les conflits de schéma dans toute l'entreprise | Gouvernance de la configuration | Un document de paramètres unique identifié par type=general et name=customFields — un schéma, une source |
| Conserve les données personnalisées sur le registre | Gouvernance de la configuration | Valeurs conservées directement dans le document de l'entité, saisies aux côtés des attributs standard |
Pourquoi Priverion
Les champs personnalisés ne sont pas un ajout greffé. Ils vivent au sein de la même plateforme unifiée de confidentialité et de sécurité de l'information que vos registres, vos risques et vos fournisseurs — de sorte que les métadonnées que vous ajoutez sont stockées sur le registre lui-même et exportées avec lui, et non isolées dans un outil distinct. Contrairement aux plateformes GRC généralistes qui traitent la configuration comme une prestation de services payante, ici un administrateur étend un schéma depuis les paramètres, l'applique par type d'entité et le voit s'afficher immédiatement — sans qu'un développeur n'intervienne.


