GC Datenschutz-Folgenabschätzung

Diese Seite ist eine öffentliche Zusammenfassung der Datenschutz-Folgenabschätzung (PIA), die vom Softwareherausgeber (Realizer Services Inc.) für AccessPoint erstellt wurde und auf die Directive on Privacy Impact Assessment des Treasury Board of Canada Secretariat (TBS) abgestimmt ist. Sie dokumentiert die Bestände personenbezogener Daten, die Informationsflüsse, die Datenschutzrisiken und die im Produkt integrierten Schutzmaßnahmen.

Die PIA des Herausgebers deckt die technischen und architektonischen Abschnitte ab und soll kanadische Bundesinstitutionen dabei unterstützen, ihre eigene PIA zu erstellen. Die bereitstellende Institution ergänzt die institutionellen Angaben (institutioneller Überblick, Aufbewahrungsfristen, Vereinbarungen zum Informationsaustausch und Freigabe) und reicht die vollständige PIA bei TBS und dem Office of the Privacy Commissioner (OPC) ein. Die vollständige PIA ist auf Anfrage für Kunden verfügbar – siehe den Schlusshinweis.

Die vollständige technische Architektur finden Sie auf der Seite Technische Architektur. Das ITSG-33-Sicherheitskontroll-Mapping finden Sie auf der Seite GC-Sicherheitskontrollen-Referenz.

Zweck und Geltungsbereich

AccessPoint ist eine Plattform für Informationszugang und Datenschutzmanagement, die staatliche Institutionen dabei unterstützt, Informationszugangs- und Datenschutzprogramme in Übereinstimmung mit dem Access to Information Act (ATIA), dem Privacy Act und gleichwertigen provinziellen/internationalen Regelungen zu verwalten. Ihre Hauptfunktion ist die Verwaltung von Anträgen auf Betroffenenauskunft/Informationszugang – der gesamte Lebenszyklus von der Erfassung über die Zuweisung, Dokumentensammlung, Prüfung und Schwärzung bis zur Antwortzusammenstellung.

Über die Antragsbearbeitung hinaus unterstützt AccessPoint auch das umgebende Datenschutzprogramm: Datenschutz-Folgenabschätzungen (PIA-/AIA-/Sicherheitsbewertungen), Management von Datenschutzvorfällen und -verletzungen (einschließlich Workflows zur Meldung von Datenschutzverletzungen), Beschwerden und Widersprüche, ein Datenschutz-Risikoregister und Verpflichtungsregister sowie Verzeichnisse von Verarbeitungstätigkeiten (ROPA). Diese Module verarbeiten zusätzliche Kategorien personenbezogener Daten und unterliegen denselben Schutzmaßnahmen, Rollen, dem Audit-Ledger und den Datenresidenz-Garantien wie der Kern der Antragsverwaltung.

Geschäftsprozess: Erfassung (ein SAO erstellt den Antrag) → Zuweisung (Custodians erhalten bereinigte Anweisungen ohne PII des Antragstellers) → Dokumentensammlung → Prüfung und Schwärzung → Antwortzusammenstellung → Abschluss (die Aufbewahrungsfrist beginnt).

Betroffene Personen: Antragsteller; Beschäftigte der Institution (SAOs, Administratoren), deren Aktionen im Audit-Trail erfasst werden; Custodians und Contributors (die keinen Zugriff auf PII des Antragstellers haben); Dritte, deren PI in geprüften Dokumenten erscheinen kann; betroffene Personen, die auf Kategorieebene in ROPA und Bewertungen beschrieben werden; von einem Datenschutzvorfall betroffene Personen; Beschwerdeführer und Beschwerdebeteiligte; sowie Konsultationskontakte.

Rechtsgrundlage: Erhebung und Nutzung stützen sich in erster Linie auf den ATIA (§§ 4, 6, 9, 19) und den Privacy Act (§§ 4, 5, 7, 8(2)(m) sowie das Auskunftsrecht des Einzelnen).

Inventar personenbezogener Daten

Erhobene und verarbeitete personenbezogene Daten

NICHT erhobene personenbezogene Daten

AccessPoint erhebt oder verarbeitet nicht: Sozialversicherungsnummern; Finanzinformationen (Bankkonten, Kreditkarten); Gesundheits- oder Krankenakten als strukturierte Daten (sie können in geprüften Dokumenten erscheinen); biometrische Daten; Vorstrafeninformationen; Standortdaten; oder Cookies/Tracking-Identifikatoren.

Hinweis: IP-Adressen und User-Agent-Strings werden nur in begrenzten Kontexten (Attestierungssignatur und Protokollierung von Dokumentzugriffen) zu forensischen Prüfungszwecken erfasst, wie oben aufgeführt. Allgemeines Surfverhalten und Geräte-Fingerprinting werden nicht erfasst.

Sensible personenbezogene Daten in Dokumenten

Während des ATIA-Prozesses gesammelte Dokumente können jede Kategorie personenbezogener Daten enthalten, einschließlich sensibler PI über Dritte. AccessPoint speichert und zeigt Dokumente in der Vorschau an und erleichtert deren Schwärzung, und — zur Unterstützung der Prüfwerkzeuge — extrahiert es den Klartext jedes Dokuments in die Datenbank (mit optionaler OCR reiner Bildscans über eine im Abonnement befindliche Azure AI Document Intelligence-Ressource). Dieser extrahierte Text treibt die Inhaltssuche an (optional indiziert in der eigenen Azure AI Search-Ressource der Institution), die Duplikaterkennung, musterbasierte/regelbasierte Schwärzungsvorschläge sowie — sofern die optionale AI Assist-Komponente bereitgestellt ist — maschinell erzeugte Vorschläge und Zusammenfassungen. All diese Verarbeitung erfolgt innerhalb des eigenen Azure-Abonnements der Institution, und jede maschinell erzeugte Schwärzung oder jeder Vorschlag ist ein Vorschlag: Die Klassifizierung und Ausnahmebehandlung von PI innerhalb von Dokumenten wird von geschulten SAOs mithilfe der integrierten Prüfwerkzeuge entschieden.

Microsoft 365-Datensatzerfassung (Opt-in, durch Feature-Toggle gesteuert): Ein Custodian kann seine eigenen Microsoft 365-Datensätze – Outlook-E-Mail, Outlook-Kalender, OneNote, Teams-Chats, Microsoft Lists oder Copilot-Interaktionsverlauf – als antwortrelevanten Datensatz erfassen. Die Erfassung verwendet stets die eigene delegierte Identität des angemeldeten Benutzers und ist auf die eigenen Daten dieses Benutzers beschränkt (der Copilot-Abruf erfolgt nur anwendungsbasiert (app-only), da keine delegierte Graph-Berechtigung existiert, ist aber serverseitig stets auf die eigene Entra-Objekt-ID des angemeldeten Benutzers beschränkt – niemals mandantenweit). Erfasste Inhalte werden in ein PDF gerendert und durchlaufen den normalen Prüf-/Schwärzungs-Workflow. Die Kalendererfassung schließt standardmäßig als Privat/Persönlich/Vertraulich markierte Elemente aus.

Analyse des Flusses personenbezogener Daten

Der Benachrichtigungspfad veranschaulicht die Kontrolle „keine PI des Antragstellers an den Herausgeber":

Event (e.g., assignment created)
        │
        ▼
  API Notification Dispatch Service
        │
        ├── PII Filter: strips requestor PI for Custodian/Contributor templates
        │
        ├──► Email: Graph Mail.Send → Institution's shared mailbox → Recipient
        │    (via managed identity or institution's app registration)
        │
        └──► Teams: API → Realizer Platform API → Graph TeamsActivity.Send → Recipient
             (sends: user ID, activity type, actor name, request number, preview text — NO requestor PI)

Datenschutz-Risikobewertung

Risikobereichs-Scores

Gemäß dem standardisierten TBS-Rahmenwerk:

Gesamtrisikoniveau: Moderat – üblich für ein Verwaltungsprogramm, das PI externer Personen verarbeitet, gemindert durch starke technische Kontrollen (Verschlüsselung, RBAC, PII-Filterung, Datensouveränität).

Technische und administrative Schutzmaßnahmen

Authentifizierung und Zugriffssteuerung

Verschlüsselung

Netzwerksicherheit

Überwachung und Audit

Administrative Schutzmaßnahmen

Administratoren weisen Rollen über die Einstellungen zu; Rollenänderungen werden sofort wirksam. Eine Application Access Policy beschränkt Mail.Send ausschließlich auf das dafür vorgesehene freigegebene Postfach. Konfigurationsänderungen werden über versionierte Rechtsordnungspakete mit Installations-Audit-Protokollierung angewendet. Mitarbeiterschulungen, die Richtlinie zur akzeptablen Nutzung und Verfahren zur Reaktion auf Datenschutzverletzungen werden von der Institution festgelegt.

Drittanbieterdienste und Datenweitergabe

Optionale Azure-KI-Dienste. Die drei oben genannten KI-Ressourcen sind keine Dienste des Herausgebers: Jede wird im eigenen Abonnement und in der eigenen Region der Institution bereitgestellt, authentifiziert sich ausschließlich über die verwaltete Identität des App Service (API-Schlüssel-Zugriff deaktiviert) und sendet nichts an Realizer Services. Jede KI-Ausgabe ist ein Vorschlag, ein bearbeitbarer Entwurf oder eine schreibgeschützte Antwort — das Personal entscheidet; Funktionsschalter je Funktion und Mandant sowie ein monatliches Token-Budget (das die gesamte KI-Verarbeitung hart stoppt) sorgen für Governance; Microsoft trainiert keine Modelle mit den Daten; und AccessPoint speichert nur Aufrufmetadaten, niemals Prompt- oder Antwortinhalte. Wo die Inferenz von Azure OpenAI verarbeitet wird, hängt vom bei der Bereitstellung gewählten Bereitstellungstyp ab (global oder EU-/US-Datenzone) — Institutionen sollten diese Wahl mit ihren Residenzanforderungen abgleichen. Für einen Antrag erstellte Fall-Audit-Exports enthalten eine Offenlegung der KI-Beteiligung (nur Metadaten), und dieselbe Information ist im Aktivitäts-Feed jedes Datensatzes sichtbar.

Kernaussage: Es werden keine PI des Antragstellers, keine Dokumentinhalte und keine Antragsdetails an Realizer Services oder eine externe Partei übertragen. Die gesamte Dokumentkonvertierung und Schwärzungsverarbeitung erfolgt innerhalb des institutionseigenen App Service, und die optionale Such-, OCR- und KI-Verarbeitung erfolgt innerhalb des eigenen Azure-Abonnements der Institution.

Anwendbare Personal Information Banks

Institutionen sollten die anwendbaren PIBs bestätigen und prüfen, ob für ihre spezifische Bereitstellung neue PIBs erforderlich sind.

Verfügbarkeit der vollständigen PIA

Die vollständige Datenschutz-Folgenabschätzung – einschließlich des vollständigen Inventars personenbezogener Daten, der detaillierten Analyse von Erhebung/Nutzung/Offenlegung/Aufbewahrung/Richtigkeit, der Rechtsgrundlagen und der Datenflussdiagramme – ist auf Anfrage für Kunden und Interessenten verfügbar. Bereitstellende Institutionen nutzen sie als technische und architektonische Grundlage für ihre eigene PIA und ergänzen den institutionellen Überblick, die Aufbewahrungsfristen, die Vereinbarungen zum Informationsaustausch und die Freigabe, bevor sie diese bei TBS und dem Office of the Privacy Commissioner einreichen.