Ocena skutków dla prywatności GC

Ta strona zawiera publiczne podsumowanie oceny skutków dla prywatności (Privacy Impact Assessment, PIA) przygotowanej przez wydawcę oprogramowania (Realizer Services Inc.) dla AccessPoint, zgodnej z Directive on Privacy Impact Assessment Treasury Board of Canada Secretariat (TBS). Dokumentuje zasoby danych osobowych, przepływy informacji, zagrożenia dla prywatności oraz zabezpieczenia wbudowane w produkt.

PIA wydawcy obejmuje sekcje techniczne i architektoniczne i ma na celu pomóc kanadyjskim instytucjom federalnym w uzupełnieniu własnej PIA. Instytucja wdrażająca uzupełnia dane instytucjonalne (przegląd instytucjonalny, harmonogramy przechowywania, umowy o wymianie informacji oraz zatwierdzenie) i przekazuje wypełnioną PIA do TBS oraz Office of the Privacy Commissioner (OPC). Pełna PIA jest dostępna dla klientów na życzenie — zobacz uwagę końcową.

Pełna architektura techniczna znajduje się na stronie Architektura techniczna. Mapowanie kontroli bezpieczeństwa ITSG-33 znajduje się na stronie Referencja kontroli bezpieczeństwa GC.

Cel i zakres

AccessPoint to platforma do zarządzania dostępem do informacji i ochroną prywatności, która pomaga instytucjom rządowym administrować programami dostępu i ochrony prywatności zgodnie z Access to Information Act (ATIA), Privacy Act oraz równoważnymi reżimami prowincjonalnymi/międzynarodowymi. Jej podstawową funkcją jest zarządzanie wnioskami o dostęp do danych osobowych / dostęp do informacji — pełny cykl życia od przyjęcia, przez przydzielenie, zbieranie dokumentów, przegląd, redakcję, po pakowanie odpowiedzi.

Poza obsługą wniosków AccessPoint wspiera również otaczający program ochrony prywatności: oceny skutków dla prywatności (oceny PIA/AIA/Security), zarządzanie incydentami prywatności i naruszeniami (w tym przepływy powiadomień o naruszeniach), skargi i odwołania, rejestr ryzyka w zakresie prywatności i rejestr zobowiązań oraz rejestry czynności przetwarzania (ROPA). Te moduły przetwarzają dodatkowe kategorie danych osobowych i są objęte tymi samymi zabezpieczeniami, rolami, rejestrem audytowym oraz gwarancjami rezydencji danych, co rdzeń zarządzania wnioskami.

Proces biznesowy: przyjęcie (SAO tworzy wniosek) → przydzielenie (osoby w roli Custodian otrzymują zanonimizowane instrukcje bez danych osobowych wnioskodawcy) → zbieranie dokumentów → przegląd i redakcja → pakowanie odpowiedzi → zamknięcie (rozpoczyna się bieg terminu przechowywania).

Osoby, których to dotyczy: wnioskodawcy; pracownicy instytucji (SAO, Administratorzy), których działania są rejestrowane w śladzie audytu; osoby w rolach Custodian i Contributor (które nie mają dostępu do danych osobowych wnioskodawcy); osoby trzecie, których dane osobowe mogą pojawić się w dokumentach poddanych przeglądowi; osoby, których dane dotyczą, opisane na poziomie kategorii w ROPA i ocenach; osoby dotknięte incydentem prywatności; skarżący i strony postępowania skargowego; oraz osoby kontaktowe konsultacji.

Podstawa prawna: zbieranie i wykorzystywanie danych opiera się przede wszystkim na ATIA (art. 4, 6, 9, 19) oraz Privacy Act (art. 4, 5, 7, 8(2)(m) oraz prawie jednostki do dostępu).

Inwentarz danych osobowych

Zbierane i przetwarzane dane osobowe

Dane osobowe, które NIE są zbierane

AccessPoint nie zbiera ani nie przetwarza: numerów ubezpieczenia społecznego (Social Insurance Number); informacji finansowych (rachunki bankowe, karty kredytowe); dokumentacji zdrowotnej lub medycznej jako danych strukturalnych (mogą one pojawić się w dokumentach poddanych przeglądowi); danych biometrycznych; informacji o karalności; danych lokalizacyjnych ani plików cookie/identyfikatorów śledzących.

Uwaga: adresy IP i ciągi user agent są przechwytywane wyłącznie w ograniczonych kontekstach (podpisywanie atestacji i rejestrowanie dostępu do dokumentów) w celach audytu forensycznego, zgodnie z powyższym zestawieniem. Ogólne zachowania przeglądania oraz odciski cyfrowe urządzeń (device fingerprinting) nie są zbierane.

Wrażliwe dane osobowe w dokumentach

Dokumenty zebrane w trakcie procesu ATIA mogą zawierać dowolną kategorię danych osobowych, w tym wrażliwe dane osobowe dotyczące osób trzecich. AccessPoint przechowuje dokumenty, umożliwia ich podgląd i ułatwia redakcję, a także — aby wspierać narzędzia przeglądu — wyodrębnia zwykły tekst każdego dokumentu do bazy danych (z opcjonalnym OCR skanów obrazowych za pomocą zasobu Azure AI Document Intelligence działającego w ramach subskrypcji instytucji). Ten wyodrębniony tekst zasila wyszukiwanie treści (opcjonalnie indeksowane we własnym zasobie Azure AI Search instytucji), wykrywanie duplikatów, sugestie redakcji oparte na wzorcach/regułach oraz — gdy wdrożony jest opcjonalny komponent AI Assist — generowane maszynowo sugestie i podsumowania. Całe to przetwarzanie odbywa się w ramach własnej subskrypcji Azure instytucji, a każda maszynowo wygenerowana redakcja lub sugestia jest jedynie propozycją: klasyfikacja i wyłączanie danych osobowych w dokumentach są ustalane przez przeszkolonych SAO za pomocą wbudowanych narzędzi przeglądu.

Przechwytywanie rekordów Microsoft 365 (opcjonalne, kontrolowane przełącznikiem funkcji): osoba w roli Custodian może przechwycić własne rekordy Microsoft 365 — e-mail Outlook, kalendarz Outlook, OneNote, czaty Teams, Microsoft Lists lub historię interakcji z Copilot — jako dokument odpowiedni dla wniosku. Przechwytywanie zawsze wykorzystuje własną, delegowaną tożsamość zalogowanego użytkownika i jest ograniczone do danych własnych tego użytkownika (pobieranie danych Copilot odbywa się w trybie wyłącznie aplikacyjnym, ponieważ nie istnieje delegowane uprawnienie Graph, lecz jest zawsze ograniczone po stronie serwera do własnego identyfikatora obiektu Entra zalogowanego użytkownika — nigdy w skali całej dzierżawy). Przechwycona treść jest renderowana do formatu PDF i wchodzi w standardowy przepływ przeglądu/redakcji. Przechwytywanie kalendarza domyślnie wyklucza elementy oznaczone jako Prywatne/Osobiste/Poufne.

Analiza przepływów danych osobowych

Ścieżka powiadomień ilustruje mechanizm kontrolny „brak danych osobowych wnioskodawcy dla wydawcy”:

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)

Ocena ryzyka dla prywatności

Wyniki punktowe obszarów ryzyka

Zgodnie ze standardowym ramowym modelem TBS:

Ogólny poziom ryzyka: Umiarkowany — standardowy dla programu administracyjnego przetwarzającego dane osobowe osób zewnętrznych, łagodzony przez silne kontrole techniczne (szyfrowanie, RBAC, filtrowanie danych osobowych, suwerenność danych).

Zabezpieczenia techniczne i administracyjne

Uwierzytelnianie i kontrola dostępu

Szyfrowanie

Bezpieczeństwo sieciowe

Monitorowanie i audyt

Zabezpieczenia administracyjne

Administratorzy przypisują role za pośrednictwem Ustawień; zmiany ról obowiązują natychmiast. Application Access Policy ogranicza Mail.Send wyłącznie do wyznaczonej współdzielonej skrzynki pocztowej. Zmiany konfiguracji są stosowane za pomocą wersjonowanych pakietów jurysdykcyjnych z rejestrowaniem audytu instalacji. Szkolenia personelu, polityka dopuszczalnego użytkowania oraz procedury reagowania na naruszenia są określane przez instytucję.

Usługi osób trzecich i udostępnianie danych

Opcjonalne usługi Azure AI. Trzy powyższe zasoby AI nie są usługami wydawcy: każdy z nich jest wdrażany we własnej subskrypcji i regionie instytucji, uwierzytelnia się wyłącznie za pomocą tożsamości zarządzanej App Service (dostęp za pomocą klucza API jest wyłączony) i nie wysyła niczego do Realizer Services. Każdy wynik AI jest sugestią, edytowalną wersją roboczą lub odpowiedzią tylko do odczytu — decyduje personel; nadzór zapewniają przełączniki dla poszczególnych funkcji na poziomie dzierżawy oraz miesięczny budżet tokenów (który twardo zatrzymuje całe przetwarzanie AI); Microsoft nie trenuje modeli na tych danych; a AccessPoint przechowuje wyłącznie metadane wywołań, nigdy treść promptów ani odpowiedzi. Miejsce przetwarzania wnioskowania (inference) Azure OpenAI zależy od typu wdrożenia wybranego w chwili wdrażania (strefa danych globalna lub UE/USA) — instytucje powinny potwierdzić ten wybór względem swoich wymagań dotyczących rezydencji danych. Pakiety dowodowe eksportowane dla wniosku zawierają ujawnienie udziału AI (wyłącznie metadane), a ta sama informacja jest widoczna w kanale aktywności każdego rekordu.

Kluczowy punkt: żadne dane osobowe wnioskodawcy, treść dokumentów ani szczegóły wniosków nie są przesyłane do Realizer Services ani żadnej strony zewnętrznej. Całe przetwarzanie konwersji i redakcji dokumentów odbywa się w ramach własnego App Service instytucji, a opcjonalne przetwarzanie wyszukiwania, OCR i AI odbywa się w ramach własnej subskrypcji Azure instytucji.

Właściwe banki danych osobowych

Instytucje powinny potwierdzić właściwe PIB oraz czy dla ich konkretnego wdrożenia wymagane są nowe PIB.

Dostępność pełnej PIA

Pełna ocena skutków dla prywatności — obejmująca kompletny inwentarz danych osobowych, szczegółową analizę zbierania/wykorzystania/ujawniania/przechowywania/dokładności, podstawy prawne oraz diagramy przepływu danych — jest dostępna dla klientów i potencjalnych klientów na życzenie. Instytucje wdrażające wykorzystują ją jako techniczną i architektoniczną podstawę własnej PIA, uzupełniając przegląd instytucjonalny, harmonogramy przechowywania, umowy o wymianie informacji oraz zatwierdzenie przed przekazaniem jej do TBS oraz Office of the Privacy Commissioner.