Erweitern Sie jeden Datensatztyp um Ihre eigenen Felder
Die Metadaten, die Ihr Schema nie eingeplant hat, landen ausserhalb des Datensatzes
Jedes Datenschutz- und Sicherheitsprogramm erfasst Metadaten, die das Standardschema nie vorgesehen hat — einen internen Asset-Eigentümer, einen Geschäftsbereichs-Code, eine Referenz, die Ihr Auditor auf jedem Datensatz erwartet. Das feste Schema bietet dafür keinen Platz.
Also landen die Daten in einer separaten Tabelle, einer Freitextnotiz oder im Postfach von jemandem — losgelöst vom Datensatz, den sie beschreiben, und beim Export unsichtbar.
Die Alternative ist schlimmer: ein Change-Request an die Entwicklung für ein einziges Feld, das Warten auf einen Release-Zyklus, um etwas zu erfassen, das Ihr Team schon gestern brauchte.
Was Sie mit benutzerdefinierten Feldern tun können
- Definieren Sie Vorlagen für benutzerdefinierte Felder pro Entitätstyp direkt in den allgemeinen Einstellungen.
- Stellen Sie diese Felder dynamisch auf den Entitäts-Detailseiten dar — ohne Codeänderung, ohne Release.
- Speichern Sie benutzerdefinierte Werte im Datensatz selbst, abgelegt im zugrunde liegenden Dokument, nicht in einem separaten System.
- Behalten Sie ein konsistentes Schema pro Unternehmen über ein einziges Einstellungsdokument, sodass Definitionen weder kollidieren noch auseinanderdriften können.
- Erfassen Sie benutzerdefinierte Daten zusammen mit den Standardattributen, sodass sie beim Export mit dem Datensatz wandern.
Was es Ihrem Programm bringt
- Erfassen Sie organisationsspezifische Metadaten auf den Datensätzen, die zählen — statt sie in Tabellen verstreuen zu lassen, die veralten.
- Umgehen Sie die Entwicklungs-Warteschlange für routinemässige Schemaänderungen; ein Administrator fügt ein Feld in den Einstellungen hinzu, statt ein Entwicklerticket einzureichen.
- Halten Sie zusätzliche Attribute an einem Ort über alle Datensatztypen hinweg, sodass jeder Eigentümer, Code oder jede Referenz auf dem Datensatz lebt — nicht daneben.
- Exportieren Sie vollständige Datensätze mit benutzerdefinierten und Standardfeldern zusammen, sodass vor einem Audit nichts von Hand abgeglichen werden muss.
Für Compliance entwickelt
Benutzerdefinierte Felder werden als Konfiguration verwaltet, nicht als Code — und genau das hält sie unternehmensweit kontrolliert und konsistent.
| Was das DPMS leistet | Zugeordnet zu | Wie |
|---|---|---|
| Zentralisiert Felddefinitionen pro Entitätstyp | Konfigurations-Governance | In den allgemeinen Einstellungen konfigurierte Vorlagen, angewendet überall dort, wo diese Entität dargestellt wird |
| Verhindert Schemakollisionen im gesamten Unternehmen | Konfigurations-Governance | Ein Singleton-Einstellungsdokument mit dem Schlüssel type=general und name=customFields — ein Schema, eine Quelle |
| Hält benutzerdefinierte Daten auf dem Datensatz | Konfigurations-Governance | Werte werden direkt im Dokument der Entität gespeichert, erfasst zusammen mit den Standardattributen |
Warum Priverion
Benutzerdefinierte Felder sind kein Aufsatz. Sie leben innerhalb derselben einheitlichen Datenschutz- und InfoSec-Plattform wie Ihre Datensätze, Risiken und Lieferanten — sodass die Metadaten, die Sie hinzufügen, im Datensatz selbst gespeichert und mit ihm exportiert werden, statt in einem separaten Tool festzustecken. Anders als universelle GRC-Plattformen, die Konfiguration als kostenpflichtigen Dienstleistungsauftrag behandeln, erweitert hier ein Administrator ein Schema aus den Einstellungen heraus, wendet es pro Entitätstyp an und sieht es sofort dargestellt — ohne Entwickler im Spiel.
Fragen, die CISOs vor einer Demo stellen
Kann ich benutzerdefinierte Felder ohne Entwickler hinzufügen?
Wo werden die benutzerdefinierten Werte gespeichert?
Können verschiedene Datensatztypen unterschiedliche Felder haben?
Erscheinen benutzerdefinierte Felder in meinen Exporten?
Verwandte Fähigkeiten entdecken
Bereit, die Metadaten zu erfassen, die Ihrem Schema fehlen?
