Verändert Avalon Daten in meinem Quellsystem?

Nein. Avalon schreibt ausschließlich in eigens angelegte u_avalon_*-Felder (bei der OneTrust®-Plattform in Custom-Fields) zurück. Es werden keine neuen Objekte angelegt und keine Stammdaten oder Systemfelder verändert.

Sind die Schnittstellen bidirektional?

Ja. Objekte und Beziehungen werden importiert; GRC-, Risiko- und Schutzbedarfswerte werden kontrolliert in die dafür vorgesehenen Felder zurückgeschrieben. Pro Attribut legen Sie fest, welches System führt.

Wie werden Konflikte behandelt?

Abweichende Werte werden nicht still überschrieben, sondern landen in einer Konflikt-Inbox zur Entscheidung – etwa bei Duplikaten, Owner-Drift oder unterschiedlichem Lebenszyklus-Status.

Interoperabilität · Nicht-invasiv

Avalon fügt sich in Ihre bestehende Tool-Landschaft ein.

Avalon verbindet sich mit Systemen, die Sie bereits betreiben – und schreibt dort ausschließlich in eigens angelegte u_avalon_*-Felder zurück. Keine neuen Objekte, keine veränderten Stammdaten: Ihr Quellsystem bleibt führend.

Integration besprechen Alle Module ansehen

Bidirektional
Nur u_avalon_*-Felder
OAuth 2.0
Konflikt-Inbox

So fließen Daten – nicht-invasiv

AvalonGRC-Bewertung · Audit-Trail

Rückschreiben: nur u_avalon_*

Import: Objekte & Beziehungen

Ihr Quellsystem

Stammdaten · Systemfelderunverändert

u_avalon_*beschreibbar

Source-of-Record je Attribut · Konflikt-Inbox statt stiller Überschreibung

Prinzip

Nicht-invasiv by Design

Integration heißt bei Avalon: andocken, ohne einzugreifen. Vier Garantien stellen sicher, dass Ihr Quellsystem führend bleibt – derselbe Anspruch wie bei „KI mit Kontrolle“.

Nur u_avalon_*-Felder

Avalon schreibt in Fremdsystemen ausschließlich in eigens dafür angelegte u_avalon_*-Felder zurück – Risiko-, Schutzbedarfs- und GRC-Attribute, sauber von Ihren Daten getrennt.

Keine Objekt-Anlage

Avalon legt keine neuen Objekte an und verändert keine Stammdaten oder Systemfelder. Bestehende Datensätze bleiben unangetastet.

Source-of-Record je Attribut

Pro Attribut legen Sie fest, welches System führt. So bleibt jederzeit eindeutig, woher ein Wert stammt.

Konflikt-Inbox

Weichen Werte voneinander ab, landet die Abweichung zur Entscheidung in einer Inbox – statt still überschrieben zu werden. Der Mensch entscheidet.

Dasselbe Prinzip wie bei der Avalon-KI: automatisieren, ohne Kontrolle abzugeben.

CMDB & Assets

Asset- und CMDB-Anbindung

Bestehende Configuration-Management-Daten mit dem Avalon-CMDB und der ISMS-Asset-Ebene verbinden – bidirektional und nicht-invasiv.

Die CMDB-Föderation (Jira sowie die ServiceNow®-CMDB-Föderation) gehört zum Avalon-CMDB-Modul; dieses wird pro Mandant im Onboarding aktiviert (Pilot) und ist standardmäßig deaktiviert. Der ServiceNow®-Abgleich auf ISMS-Asset-Ebene ist davon unabhängig verfügbar.

Jira-Integration

Jira Service Management Assets ↔ Avalon-CMDB

Verbindet bestehende Jira Service Management Assets mit dem Avalon-CMDB – Objekte und Beziehungen kommen nach Avalon, GRC-Attribute gehen kontrolliert zurück.

Richtung: Bidirektional: Import von Objekten und Beziehungen (per AQL) als Avalon-CIs; Rückschreiben von GRC-Attributen ausschließlich in u_avalon_*-Felder (partielles PATCH).
Ausgetauschte Objekte: Asset-Objekte und ihre Beziehungen aus Jira Service Management Assets; zurück nur Avalon-GRC-Attribute in u_avalon_*-Feldern.
Authentifizierung: Basic-Authentifizierung, Personal Access Token oder OAuth 2.0.
Betrieb: Cloud und Data Center.
Synchronisation: Voll- oder Delta-Sync (Delta nutzt verfügbare Aktualisierungs-Zeitstempel, sonst Voll-Abgleich), Feldmapping und Source-of-Record je Attribut.
Sicherheit: Keine Objekt-Anlage in Jira, keine Änderung von Stammdaten oder Systemfeldern.

ServiceNow®-Integration

Bestehende ServiceNow®-CMDB ↔ Avalon – CMDB-Föderation und ISMS-Asset-Abgleich

Avalon ergänzt eine bestehende ServiceNow®-CMDB, statt sie zu ersetzen – auf zwei Ebenen: als CI-Föderation mit dem Avalon-CMDB-Modul und als Asset-Abgleich mit dem Avalon-ISMS. Configuration Items und Beziehungen kommen nach Avalon; Risiko- und Schutzbedarfswerte gehen ausschließlich in u_avalon_*-Felder zurück. CI-Stammdaten bleiben in der ServiceNow®-Plattform führend.

Richtung: Bidirektional auf beiden Ebenen: Pull von Configuration Items (cmdb_ci) und Beziehungen (cmdb_rel_ci) nach Avalon; Push von Risiko- und Schutzbedarfswerten ausschließlich in u_avalon_*-Felder (PATCH, keine Objekt-Anlage).
Ausgetauschte Objekte: Configuration Items und Beziehungen aus der ServiceNow®-CMDB; zurück nur Risiko- und Schutzbedarfswerte in u_avalon_*-Feldern.
Authentifizierung: OAuth 2.0; für die CMDB-Föderation zusätzlich Basic- oder Bearer-Authentifizierung.
Betrieb: ServiceNow®-Instanz über die Table-API.
Synchronisation: Voll- und Delta-Abgleich per Watermark (sys_updated_on), optionaler Filter (z. B. operational_status); Rückschreiben über eine Push-Queue mit Dead-Letter-Handling.
Sicherheit: Schreiben ausschließlich in u_avalon_*-Felder; keine Änderung von CI-Stammdaten, keine Objekt-Anlage. Konflikt-Inbox mit Admin-Entscheidung (Duplikat, retired-vs-active, Owner-Drift).

Datenschutz & TPRM

Datenschutz- und TPRM-Koexistenz

Avalon und Ihre bestehende Datenschutz-Plattform arbeiten nebeneinander – mit klaren Master-Rollen je Datendomäne.

OneTrust®-Integration

Datenschutz- und TPRM-Koexistenz – Avalon neben der OneTrust®-Plattform

Koexistenz statt Ersatz: Avalon ist Master für Prozess-, CIF- und Schutzbedarfsdaten und schreibt diese in Custom-Fields der OneTrust®-Plattform; Vendor-Assessments kommen per Webhook zurück (TPRM-Kontext).

Richtung: Bidirektional: Push von Prozess-, CIF- und Schutzbedarfswerten in OneTrust®-Custom-Fields; Inbound-Webhook für Vendor-Assessments zurück nach Avalon.
Ausgetauschte Objekte: Hinaus: Prozess-, CIF- und Schutzbedarfsattribute in OneTrust®-Custom-Fields. Herein: Vendor-Assessment-Ergebnisse per Webhook.
Authentifizierung: OAuth 2.0 Client Credentials.
Betrieb: SaaS-Koexistenz – keine CMDB-Integration.
Synchronisation: Zeitgesteuerter Voll- und Delta-Sync, Dry-Run, Push-Queue mit Dead-Letter-Handling; Inbound-Webhook mit HMAC-SHA256, Anti-Replay und Idempotenz.
Sicherheit: In Avalon Schreiben ausschließlich in onetrust_*-Tabellen (kein Zugriff auf den ISMS-Core); extern nur in Custom-Fields, keine Objekt-Anlage.

Überblick

Fähigkeiten im Vergleich

Alle Schnittstellen bidirektional und nicht-invasiv – hier die wichtigsten Merkmale kompakt.

Fähigkeiten im Vergleich
System	Ebene	Richtung	Authentifizierung	Betrieb	Synchronisation	Konflikt-Handling
Jira	CMDB & Assets	Bidirektional · nur u_avalon_*	Basic · PAT · OAuth 2.0	Cloud + Data Center	Delta- oder Full-Sync	Source-of-Record je Attribut · Konflikt-Inbox
ServiceNow® · CMDB	CMDB-Modul · CI-Föderation	Bidirektional · nur u_avalon_*	OAuth 2.0 · Basic · Bearer	Table-API	Voll + Delta (Watermark)	Konflikt-Inbox · SoR je Attribut
ServiceNow® · ISMS	ISMS-Asset-Inventar	Bidirektional · nur u_avalon_*	OAuth 2.0	Table-API	Delta per Watermark	Konflikt-Inbox (Duplikat · Owner-Drift · retired/active)
OneTrust®	Datenschutz & TPRM	Bidirektional · Custom-Fields + Webhook	OAuth 2.0 Client Credentials	SaaS-Koexistenz	Full + Delta · Dry-Run	HMAC-Webhook · Push-Queue + Dead-Letter

Häufige Fragen

Fragen zu Integrationen

Verändert Avalon Daten in meinem Quellsystem?: Nein. Avalon schreibt ausschließlich in eigens angelegte u_avalon_*-Felder (bei der OneTrust®-Plattform in Custom-Fields) zurück. Es werden keine neuen Objekte angelegt und keine Stammdaten oder Systemfelder verändert.
Sind die Schnittstellen bidirektional?: Ja. Objekte und Beziehungen werden importiert; GRC-, Risiko- und Schutzbedarfswerte werden kontrolliert in die dafür vorgesehenen Felder zurückgeschrieben. Pro Attribut legen Sie fest, welches System führt.
Ist OneTrust® eine CMDB-Integration?: Nein. Die Anbindung an die OneTrust®-Plattform ist eine Datenschutz- und TPRM-Koexistenz: Avalon ist Master für Prozess-, CIF- und Schutzbedarfsdaten, die OneTrust®-Plattform bleibt Master für Vendor-Stammdaten und Assessments.
Ab wann sind die CMDB-Integrationen verfügbar?: Die CMDB-Föderation (Jira und die ServiceNow®-CMDB-Föderation) gehört zum Avalon-CMDB-Modul, das pro Mandant im Onboarding aktiviert wird (Pilot) und standardmäßig deaktiviert ist. Der ServiceNow®-Abgleich auf ISMS-Asset-Ebene ist unabhängig vom CMDB-Modul verfügbar.
Wie werden Konflikte behandelt?: Abweichende Werte werden nicht still überschrieben, sondern landen in einer Konflikt-Inbox zur Entscheidung – etwa bei Duplikaten, Owner-Drift oder unterschiedlichem Lebenszyklus-Status.

Integrationen

Sprechen wir über Ihre Tool-Landschaft.

Wir zeigen Ihnen, wie Avalon an Ihre bestehenden Systeme andockt – nicht-invasiv und mit klaren Master-Rollen je Attribut.

Integration besprechen Alle Module ansehen

Marken- und Interoperabilitätshinweis

Jira ist eine Marke der Atlassian Pty Ltd. ServiceNow, das ServiceNow-Logo, Now und weitere ServiceNow-Marken sind Marken bzw. eingetragene Marken der ServiceNow, Inc. in den USA und/oder anderen Ländern. OneTrust ist eine Marke der OneTrust LLC in den USA und/oder anderen Ländern. Avalon ist mit diesen Unternehmen nicht verbunden und wird von ihnen weder gesponsert noch zertifiziert. Die Nennung dient ausschließlich der Beschreibung von Interoperabilität.