Wstępnie wypełniony szablon PIA zgodny z Directive on Privacy Impact Assessment TBS, przeznaczony dla kanadyjskich departamentów rządu federalnego wdrażających AccessPoint

Last updated: July 12, 2026 by Steve

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

Element danych Wrażliwość Źródło Cel Przechowywane w
Pełne imię i nazwisko wnioskodawcy Średnia Wnioskodawca (przez przyjęcie) Identyfikacja wnioskodawcy, korespondencja Azure SQL
Adres e-mail wnioskodawcy Średnia Wnioskodawca Korespondencja e-mail Azure SQL
Adres pocztowy wnioskodawcy Średnia Wnioskodawca Dostarczenie odpowiedzi pocztą Azure SQL
Numer telefonu wnioskodawcy Niska-Średnia Wnioskodawca Korespondencja telefoniczna Azure SQL
Organizacja wnioskodawcy Niska Wnioskodawca Raportowanie statystyczne Azure SQL
Opis wniosku Średnia Wnioskodawca Określenie zakresu wyszukiwania Azure SQL
Imię i nazwisko osoby, której dotyczy wniosek Średnia-Wysoka Wnioskodawca (przez przyjęcie) Identyfikacja osoby, której dotyczy wniosek (może różnić się od wnioskodawcy) Azure SQL
Data urodzenia osoby, której dotyczy wniosek Wysoka Wnioskodawca (przez przyjęcie) Weryfikacja tożsamości dla wniosków dotyczących prywatności Azure SQL
Nazwiska, adresy e-mail i identyfikatory obiektów Entra pracowników Niska Entra ID Identyfikacja użytkowników, powiadomienia, uwierzytelnianie, audyt Azure SQL
Ślad audytu (działania użytkowników) Niska-Średnia Generowane przez system Odpowiedzialność, zgodność Azure SQL
Dokumenty w trakcie przeglądu Potencjalnie wysoka Dokumentacja instytucji Przygotowanie odpowiedzi ATIA Azure Blob Storage
Zredagowane wersje dokumentów Średnia Generowane przez system Pakowanie odpowiedzi Azure Blob Storage
Rekordy atestacji i podpisy elektroniczne (wpisane imię i nazwisko) Niska-Średnia Osoby w roli Custodian Formalne potwierdzenie kompletności Azure SQL
Adresy IP i ciągi user agent (atestacja, dostęp do dokumentów) Niska-Średnia Przechwytywane przez system Audyt forensyczny kontekstu podpisania/dostępu Azure SQL
Komunikacja z wnioskodawcą Średnia Personel SAO Rekordy korespondencji (kierunek, metoda, data, notatki) Azure SQL
Rekordy delegacji Niska-Średnia SAO/Administrator Delegowanie odpowiedzialności urzędnika Azure SQL
Rekordy konsultacji i katalog kontaktów Niska-Średnia Personel SAO Konsultacje międzyresortowe lub zewnętrzne Azure SQL
Katalog kontaktów wnioskodawców Średnia Wnioskodawca / personel przyjmujący Wielokrotnego użytku tożsamość wnioskodawcy; wniosek odwołuje się do kontaktu zamiast przechowywać dane osobowe bezpośrednio Azure SQL
Szczegóły danych osobowych dotkniętych incydentem Potencjalnie wysoka Personel ds. prywatności/ATIP Fakty dotyczące incydentu, kategorie dotkniętych danych osobowych, ocena szkody, śledzenie powiadomień o naruszeniu Azure SQL
Strony postępowania skargowego i korespondencja Średnia Personel ds. prywatności/ATIP Tożsamość skarżącego/strony oraz obsługa skargi Azure SQL
Kategorie rejestrów czynności przetwarzania (ROPA) Niska-Średnia Personel ds. prywatności Opisy zgodne z GDPR Article 30 według kategorii osoby, której dane dotyczą / odbiorcy — nie rekordy indywidualne Azure SQL
Odpowiedzi w kwestionariuszach ocen Niska-Średnia Personel ds. prywatności / delegaci Treść PIA/AIA/Security; może opisywać dane osobowe przetwarzane przez program Azure SQL
Rekordy przechwycone z Microsoft 365 (opcjonalnie) Potencjalnie wysoka Własne dane M365 osoby w roli Custodian E-mail, kalendarz, OneNote, czaty Teams lub interakcje z Copilot przechwycone przez Custodian jako dokument odpowiedni dla wniosku Azure Blob Storage (skonwertowane pliki PDF)
Rejestr audytowy zabezpieczony łańcuchem skrótów Niska-Średnia Generowane przez system Wykrywający próby manipulacji, wyłącznie dopisywalny rejestr działań we wszystkich modułach Azure SQL

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 nie analizuje ani nie indeksuje treści dokumentów — przechowuje je, umożliwia podgląd i ułatwia redakcję. Klasyfikacja i wyłączanie danych osobowych w dokumentach jest wykonywane 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

Etap Podsumowanie
Zbieranie Dane osobowe są zbierane na podstawie ATIA art. 6 (złożenie wniosku wymaga podania imienia i nazwiska oraz adresu) oraz Privacy Act art. 4 (zbieranie związane z programem operacyjnym). Zbierane są wyłącznie dane osobowe niezbędne do przetworzenia wniosku, bezpośrednio od wnioskodawcy i wprowadzane przez personel SAO. Pola są konfigurowalne przez instytucję.
Wykorzystanie Dane osobowe wnioskodawcy są wykorzystywane wyłącznie do przetworzenia wniosku ATIA/Privacy Act. Tylko role Administrator, SAO i Reviewer mogą wyświetlać dane osobowe wnioskodawcy — osoby w rolach Custodian i Contributor nigdy ich nie widzą (egzekwowane po stronie serwera przez oprogramowanie pośredniczące filtrujące dane osobowe). Nie występuje żadne zautomatyzowane podejmowanie decyzji, profilowanie ani przetwarzanie algorytmiczne; wszystkie decyzje podejmuje przeszkolony personel. Raporty statystyczne mają wyłącznie charakter zagregowany.
Ujawnianie Pakiet odpowiedzi jest dostarczany wnioskodawcy (ATIA art. 7). Ujawnianie wewnętrzne personelowi SAO/Reviewer jest kontrolowane rolami; osoby w rolach Custodian/Contributor otrzymują wyłącznie zanonimizowane instrukcje. Powiadomienia e-mail i Teams do osób w rolach Custodian/Contributor nie zawierają danych osobowych wnioskodawcy. Wydawca otrzymuje wyłącznie identyfikator dzierżawy (walidacja licencji), metadane powiadomień (identyfikator użytkownika odbiorcy, typ aktywności, nazwa wyświetlana aktora, numer wniosku, tekst podglądu/tematu, odniesienie do powiązanego rekordu) oraz raporty instalacji pakietów konfiguracyjnych — bez danych osobowych wnioskodawcy. Microsoft przetwarza dane jako subprocesor w ramach własnej dzierżawy instytucji.
Przechowywanie i usuwanie Wbudowana funkcja przeglądu retencji stosuje konfigurowalne okresy przechowywania dla każdego typu wniosku. Trwałe usunięcie kasuje rekordy wniosków, dokumenty, przydziały, zadania, atestacje i historię audytu, i jest rejestrowane w tabeli RetentionPurgeLog. Automatyczne kopie zapasowe Azure SQL przechowują dane przez 7–35 dni w zależności od poziomu (konfigurowalne długoterminowe przechowywanie).
Dokładność Dane osobowe wnioskodawcy są wprowadzane na podstawie oryginalnego formularza wniosku; dane osobowe pracowników pochodzą z Entra ID i są odświeżane przy każdym logowaniu. Dane osobowe są przechowywane w takiej postaci, w jakiej zostały wprowadzone — system nie przekształca, nie wnioskuje ani nie wyprowadza dodatkowych 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

Ryzyko Prawdopodobieństwo Wpływ Łagodzenie Ryzyko rezydualne
Nieautoryzowany dostęp do danych osobowych wnioskodawcy Niskie Średni Sześciopoziomowe RBAC egzekwowane po stronie serwera; role Custodian/Contributor architektonicznie wykluczone z dostępu do danych osobowych; MFA Entra ID; sprawdzanie ról przy każdym żądaniu. Niskie
Naruszenie danych osobowych przez ekspozycję dokumentów Niskie-Średnie Średni-Wysoki Szyfrowanie w spoczynku (TDE, AES-256); autoryzacja oparta na rolach; brak publicznego dostępu do dokumentów; narzędzia redakcji usuwają dane osobowe przed pakowaniem odpowiedzi. Niskie-Średnie
Dane osobowe w powiadomieniach Bardzo niskie Niski Szablony Custodian/Contributor automatycznie usuwają dane osobowe; powiadomienia SAO zawierają numer wniosku, ale nie tożsamość wnioskodawcy; powiadomienia Teams zawierają wyłącznie typ powiadomienia, numer wniosku oraz nazwę zadania/przydziału. Bardzo niskie
Przesyłanie danych osobowych do wydawcy Bardzo niskie Niski Wydawca otrzymuje wyłącznie identyfikator dzierżawy (licencja) oraz metadane powiadomień — bez danych osobowych, dokumentów ani szczegółów wniosków — i nie ma stałego dostępu do zasobów Azure instytucji. Bardzo niskie
Dane osobowe poza jurysdykcją kanadyjską Zależne od konfiguracji Średni Dane są przechowywane w subskrypcji Azure instytucji, w wybranym przez nią regionie (zalecane Canada Central/East); rezydencję danych reguluje Microsoft Cloud Agreement. Do oceny przez instytucję
Niewystarczające przechowywanie/usuwanie Niskie-Średnie Średni Wbudowany przegląd retencji z konfigurowalnymi okresami i rejestrowaniem trwałego usuwania; instytucja dostosowuje harmonogramy do zezwoleń na dyspozycję Library and Archives Canada. Niskie (przy właściwej konfiguracji)
Zagrożenie wewnętrzne (nadużycie przez autoryzowanego użytkownika) Niskie Średni Kompleksowy ślad audytu z przypisaniem do użytkownika i znacznikami czasu; dostęp oparty na rolach ogranicza ekspozycję; Administratorzy kontrolują przypisania ról. Niskie

Wyniki punktowe obszarów ryzyka

Zgodnie ze standardowym ramowym modelem TBS:

Obszar ryzyka Wynik Uzasadnienie
Typ programu lub działalności 2 Administrowanie programem/działalnością (administrowanie ATIA)
Typ danych osobowych 3 Dane kontaktowe oraz potencjalnie wrażliwe rekordy w dokumentach
Partnerzy programu 2 Microsoft (subprocesor); Realizer (brak dostępu do danych osobowych)
Czas trwania programu 4 Długoterminowe/ciągłe zobowiązanie ustawowe
Populacja programu 3 Osoby zewnętrzne wykonujące prawa ustawowe
Przesyłanie danych osobowych 2 Zaszyfrowana infrastruktura chmurowa w jurysdykcji kanadyjskiej
Technologia i prywatność 2 Standardowa aplikacja webowa — brak AI, nadzoru czy biometrii
Potencjalny wpływ na jednostkę 2-3 Możliwe zakłopotanie lub szkoda reputacyjna w przypadku ujawnienia tożsamości wnioskodawcy

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

Zabezpieczenie Implementacja
Uwierzytelnianie Microsoft Entra ID z tokenami bearer JWT. Brak lokalnych kont użytkowników ani haseł.
Uwierzytelnianie wieloskładnikowe Egzekwowane przez polityki Conditional Access Entra ID instytucji.
Continuous Access Evaluation Obsługiwane — walidacja tokenu następuje przy każdym żądaniu API.
Kontrola dostępu oparta na rolach Sześć ról egzekwowanych po stronie serwera na wszystkich punktach końcowych API.
Filtrowanie danych osobowych Oprogramowanie pośredniczące po stronie serwera usuwa dane osobowe wnioskodawcy z odpowiedzi dla ról Custodian, Contributor i Reader; klient nie może go obejść.
Zarządzanie sesjami Oparte na tokenach; czas życia regulowany przez polityki Entra ID.
Bootstrap pierwszego użytkownika Pierwszy użytkownik otrzymuje role Administrator i SAO. Nie istnieją żadne domyślne ani współdzielone poświadczenia.

Szyfrowanie

Warstwa Implementacja
W transmisji Minimum TLS 1.3 na front doorze App Service; TLS 1.2+ na Azure SQL i Blob Storage; FTPS wyłączone.
W spoczynku — baza danych Azure SQL Transparent Data Encryption (TDE) z kluczami zarządzanymi przez Microsoft.
W spoczynku — dokumenty Szyfrowanie Azure Blob Storage AES-256; dostępne klucze zarządzane przez klienta (CMK).
W spoczynku — sekrety Azure Key Vault, dostęp za pośrednictwem tożsamości zarządzanej.

Bezpieczeństwo sieciowe

Zabezpieczenie Implementacja
Wyłącznie HTTPS Cały ruch HTTP jest odrzucany; HTTP/2 włączone.
CORS Ograniczone do domeny SharePoint instytucji.
Ograniczanie przepustowości (rate limiting) 600 żądań/minutę na uwierzytelnionego użytkownika.
Nagłówki bezpieczeństwa X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, Content-Security-Policy.
Płaszczyzna zarządzania Podstawowe uwierzytelnianie SCM/FTP wyłączone; zarządzanie wyłącznie przez portal Azure z Entra ID + MFA.

Monitorowanie i audyt

Zabezpieczenie Implementacja
Ślad audytu aplikacji Wszystkie działania tworzenia/aktualizacji/usuwania są rejestrowane wraz z identyfikatorem użytkownika, znacznikiem czasu, zmienionym polem oraz starymi/nowymi wartościami.
Rejestr audytowy wykrywający próby manipulacji Wyłącznie dopisywalny rejestr zabezpieczony łańcuchem skrótów (SHA-256) rejestruje działania we wszystkich modułach; integralność można zweryfikować po stronie serwera, a dla danego wniosku można wyeksportować pakiet dowodowy gotowy do postępowania sądowego.
Dziennik dostępu do dokumentów Zdarzenia podglądu i pobierania są rejestrowane wraz z identyfikatorem użytkownika, znacznikiem czasu, adresem IP i user agent. Wyłącznie do zapisu (insert-only).
Dziennik trwałego usuwania zgodnie z retencją Wszystkie operacje trwałego usunięcia są rejestrowane z przypisaniem do użytkownika.
Monitorowanie aplikacji Azure Application Insights rejestruje żądania HTTP, wyjątki i wywołania zależności (90-dniowy okres przechowywania).
Reguły alertów Konfigurowalne alerty metryczne dla błędów HTTP 5xx i wysokiego opóźnienia.
Log Analytics Scentralizowane przechowywanie logów z możliwością zapytań KQL na potrzeby dochodzeń bezpieczeństwa.

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 konfiguracyjnych 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

Usługa Rola Otrzymane dane osobowe Lokalizacja danych
Microsoft Azure Subprocesor (IaaS: App Service, SQL, Blob, Key Vault, Application Insights) Wszystkie dane aplikacji Region Azure instytucji
Microsoft 365 Podmiot przetwarzający (Graph Mail.Send, kanał aktywności Teams) oraz opcjonalnie źródło rekordów przechwyconych przez Custodian Treść powiadomień e-mail/Teams; w przypadku opcjonalnego przechwytywania — własna treść M365 danej osoby w roli Custodian Dzierżawa M365 instytucji
Realizer Services (wydawca) Wydawca oprogramowania — brak roli podmiotu przetwarzającego wobec danych osobowych klienta Brak — wyłącznie identyfikator dzierżawy + metadane powiadomień + raporty instalacji pakietów konfiguracyjnych Azure wydawcy (Kanada)
Syncfusion Wbudowana biblioteka (nie usługa) Brak — konwersja odbywa się w ramach App Service instytucji App Service instytucji

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 dokumentów (konwersja, redakcja) odbywa się w ramach własnego App Service instytucji.

Właściwe banki danych osobowych

PIB Numer rejestracyjny Opis
Access to Information Act and Privacy Act Requests PSU 901 Rekordy związane z wnioskami ATIP
Employee Personnel Records PSE 901 Nazwiska i role pracowników w śladzie audytu

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.