Betriebsstatus, Wartung und grobe Verfuegbarkeit teilen, ohne interne Systeme offenzulegen.
Nur sanitisierte Komponenten und keine personenbezogenen Viewer- oder Incident-Details.Status / Incident / Subscriber / Datenschutz
Trust Status-Kommunikation fuer aktiv.adfc.de
Trust-Status-Kommunikation fuer aktiv.adfc.de: 6 Statusflaechen, 6 Ereignistypen, 6 Publish-Gates, Score 100.
Diese oeffentliche SaferPage-Seite ist ein Status-Kommunikations-Blueprint. Sie veroeffentlicht keine echten Vorfaelle, verschickt keine Benachrichtigungen und exportiert keine Subscriber- oder Kundendaten.
Statusflaechen
Was oeffentlich, freigegeben oder nur privat kommuniziert wird
Security-, Compliance-, Subprocessor- und Produktupdates im Trust Center erklaeren.
Kategorie, Zielgruppe, Freigabe und Ablaufdatum pro Announcement setzen.Kundenorientierte Stoerungs- oder Security-Hinweise mit Update-Timeline zeigen.
Nur nach Legal/DSB/Security-Freigabe und Kommunikationsplan aktivieren.Abonnenten ueber relevante Trust-, Security- und Privacy-Aenderungen informieren.
Double-Opt-in, Abmeldung und Segment-Policy erzwingen.Vulnerability-, Patch- oder Mitigation-Hinweise transparent und kontrolliert kommunizieren.
CVE/Severity/Impact nur veroeffentlichen, wenn Missbrauchsrisiko und Kundenwirkung bewertet sind.Betroffene Kunden gezielt statt oeffentlich informieren.
Keine offenen Empfaengerlisten; Access-Scope, NDA und Auditlog respektieren.Ereignisse
Wartung, Incident, Advisory und Datenschutzmeldung getrennt behandeln
vorher ankuendigen
zeitnah aktualisieren
Incident-Bridge und DSB/Legal einbinden
Kenntniszeitpunkt und Meldeentscheidung dokumentieren
Notice-Frist und Einspruchsprozess pruefen
Version, Quelle und wirksames Datum setzen
Publish-Gates
Keine externe Meldung ohne Klassifizierung, Freigabe und Sanitization
Public Status, Approved Viewer Notice, Incident, Advisory oder interner Log-Eintrag unterscheiden.
Bei Security-, Privacy- oder Kundenwirkung vor externem Versand erforderlich.
Keine internen Hostnamen, IPs, Kundennamen, Tickets, Secrets oder personenbezogenen Details veroeffentlichen.
Started, detected, mitigated, resolved und next update getrennt dokumentieren.
Public, Approved, Access Group, Subscriber oder konkrete betroffene Kunden bewusst waehlen.
Drafts, Subscriber-Events, Zustelllogs und Viewer-Bezug befristet oder de-identifiziert halten.
Templates & Kanaele
Texte und Zustellung datenarm vorbereiten
["summary","impact_window","affected_surface","next_update_at","contact_path"]
["current_status","mitigation","remaining_impact","next_step"]
["resolved_at","root_cause_category","customer_action","follow_up"]
["severity","affected_version_or_surface","mitigation","customer_action","credits"]
["data_categories","risk_assessment","measures","rights_contact","legal_status"]
Public nur sanitisierte Komponenten.
Access-Level und NDA respektieren.
Double-Opt-in, Abmeldung, Empfaenger nur intern gehasht.
Keine Kundendaten oder Rohlogs im Chat.
Nur Feldallowlist und Domain-Hash.