Förifylld PIA-mall i linje med TBS Directive on Privacy Impact Assessment för kanadensiska federala myndigheter som inför AccessPoint

Last updated: August 06, 2026 by Steve

GC:s integritetskonsekvensbedömning (PIA)

Denna sida är en offentlig sammanfattning av integritetskonsekvensbedömningen (Privacy Impact Assessment, PIA) som utarbetats av programvaruutgivaren (Realizer Services Inc.) för AccessPoint, i linje med Treasury Board of Canada Secretariats (TBS) Directive on Privacy Impact Assessment. Den dokumenterar innehav av personuppgifter, informationsflöden, integritetsrisker och skyddsåtgärder inbyggda i produkten.

Utgivarens PIA täcker de tekniska och arkitektoniska avsnitten och är avsedd att hjälpa kanadensiska federala institutioner att färdigställa sin egen PIA. Den implementerande institutionen fyller i de institutionella detaljerna (institutionell översikt, bevarandescheman, avtal om informationsdelning och godkännande) och lämnar in den färdigställda PIA:n till TBS och Office of the Privacy Commissioner (OPC). Den fullständiga PIA:n finns tillgänglig för kunder på begäran — se den avslutande anmärkningen.

För den fullständiga tekniska arkitekturen, se sidan Teknisk arkitektur. För kartläggning av ITSG-33-säkerhetskontroller, se sidan Referens för GC-säkerhetskontroller.

Syfte och omfattning

AccessPoint är en plattform för hantering av tillgång till information och integritet som hjälper myndighetsinstitutioner att administrera program för tillgång till information och integritet i enlighet med Access to Information Act (ATIA), Privacy Act och motsvarande provinsiella/internationella regelverk. Dess primära funktion är hantering av subject access-/tillgång till information-förfrågningar – hela livscykeln från mottagande genom tilldelning, dokumentinsamling, granskning, maskering och paketering av svar.

Utöver förfrågningshantering stöder AccessPoint även det omgivande integritetsprogrammet: integritetskonsekvensbedömningar (PIA/AIA/säkerhetsbedömningar), hantering av integritetsincidenter och personuppgiftsincidenter (inklusive arbetsflöden för anmälan om personuppgiftsincidenter), klagomål och överklaganden, ett riskregister för integritetsfrågor och register över åtaganden, samt register över behandling (ROPA). Dessa moduler behandlar ytterligare kategorier av personuppgifter och omfattas av samma skyddsåtgärder, roller, granskningsliggare och garantier för dataresidens som kärnan för förfrågningshantering.

Affärsprocess: mottagande (en SAO skapar förfrågan) → tilldelning (förvaltare får sanerade instruktioner utan den sökandes personuppgifter) → dokumentinsamling → granskning och maskering → paketering av svar → avslutning (bevarandeklockan börjar).

Berörda individer: sökande; institutionens anställda (SAO:er, administratörer) vars handlingar registreras i granskningsspåret; förvaltare och medarbetare (som inte har tillgång till den sökandes personuppgifter); tredje parter vars personuppgifter kan förekomma i dokument under granskning; registrerade som beskrivs på kategorinivå i ROPA och bedömningar; individer som berörs av en integritetsincident; klagande och parter i klagomål; samt samrådskontakter.

Rättslig grund: insamling och användning vilar huvudsakligen på ATIA (avsnitt 4, 6, 9, 19) och Privacy Act (avsnitt 4, 5, 7, 8(2)(m), samt individens rätt till tillgång).

Inventering av personuppgifter

Insamlade och behandlade personuppgifter

Dataelement Känslighet Källa Syfte Lagras i
Sökandes fullständiga namn Medel Sökande (via mottagande) Identifiera sökande, korrespondens Azure SQL
Sökandes e-postadress Medel Sökande E-postkorrespondens Azure SQL
Sökandes postadress Medel Sökande Postleverans av svar Azure SQL
Sökandes telefonnummer Låg-medel Sökande Telefonkorrespondens Azure SQL
Sökandes organisation Låg Sökande Statistisk rapportering Azure SQL
Beskrivning av förfrågan Medel Sökande Definiera sökningens omfattning Azure SQL
Personens namn Medel-hög Sökande (via mottagande) Identifiera den person förfrågan avser (kan skilja sig från den sökande) Azure SQL
Personens födelsedatum Hög Sökande (via mottagande) Identitetsverifiering för integritetsförfrågningar Azure SQL
Anställdas namn, e-postadresser, Entra-objekt-ID:n Låg Entra ID Användaridentifiering, aviseringar, autentisering, granskning Azure SQL
Granskningsspår (användarhandlingar) Låg-medel Systemgenererat Ansvarighet, efterlevnad Azure SQL
Dokument under granskning Potentiellt hög Institutionens handlingar Förberedelse av ATIA-svar Azure Blob Storage
Maskerade dokumentversioner Medel Systemgenererat Paketering av svar Azure Blob Storage
Intygandeposter och e-signaturer (maskinskrivet namn) Låg-medel Förvaltare Formellt godkännande av fullständighet Azure SQL
IP-adresser och user agent-strängar (intygande, dokumentåtkomst) Låg-medel Systemregistrerat Forensisk granskning av signerings-/åtkomstkontext Azure SQL
Sökandekorrespondens Medel SAO-personal Korrespondensregister (riktning, metod, datum, anteckningar) Azure SQL
Delegeringsposter Låg-medel SAO/administratör Delegering av handläggaransvar Azure SQL
Samrådsposter och kontaktkatalog Låg-medel SAO-personal Interdepartementalt eller externt samråd Azure SQL
Kontaktkatalog för sökande Medel Sökande/mottagningspersonal Återanvändbar identitet för sökande; förfrågan länkas till en kontakt i stället för att lagra personuppgifter direkt Azure SQL
Sökandens uppförandelogg Medel ATIP-personal/systemgenererat Tillägg-endast, daterade, attribuerade uppförandeobservationer och granskningsutfall — den bevisbärande dokumentationen bakom en bedömning om grundlöst eller trakasserande beteende. Poster redigeras aldrig; borttagning är endast tillgängligt för Administrator och granskningsloggas Azure SQL
Analysmemo för sökandens uppförande Medel ATIP-personal (valfritt AI-utkast, granskat av människa) Skriftlig analys som stödjer eller avstyrker en F&V-bedömning; kan renderas som en formell PDF-post Azure SQL/Azure Blob Storage
Kontakter i leverantörsregistret Låg-medel Integritetspersonal Affärskontaktuppgifter för tredjeparts personuppgiftsbiträden/leverantörer, tillsammans med fakta om DPA/avtal och granskningsintervall Azure SQL
Detaljer om personuppgifter berörda av incident Potentiellt hög Integritets-/ATIP-personal Incidentfakta, kategorier av berörda personuppgifter, skadebedömning, spårning av anmälan om personuppgiftsincident Azure SQL
Parter i klagomål och korrespondens Medel Integritets-/ATIP-personal Identitet för klagande/part och klagomålshantering Azure SQL
Kategorier för register över behandling (ROPA) Låg-medel Integritetspersonal GDPR Article 30-beskrivningar per kategori av registrerad/mottagare — inte enskilda poster Azure SQL
Svar på bedömningsfrågeformulär Låg-medel Integritetspersonal/delegater PIA-/AIA-/säkerhetsinnehåll; kan beskriva personuppgifter som hanteras av ett program Azure SQL
Insamlade Microsoft 365-poster (valfritt) Potentiellt hög Förvaltarens egen M365-data E-post, kalender, OneNote, Teams-chattar eller Copilot-interaktioner som samlats in av förvaltaren som en relevant handling Azure Blob Storage (konverterade PDF-filer)
Extraherad dokumenttext Potentiellt hög (återspeglar dokumentinnehållet) Systemgenererat (inklusive valfri OCR av bildbaserade skanningar) Klartext extraherad för innehållssökning, dubblettidentifiering, maskeringsförslag och AI-grundning Azure SQL; indexeras valfritt i institutionens egen Azure AI Search-resurs
AI-dokumentsammanfattningar (valfritt) Medel (kan beskriva personuppgifter i dokumentet) Systemgenererat (Azure OpenAI i institutionens prenumeration) Cachad maskingenererad sammanfattning per dokument och språk, återgenereras vid innehållsändring Azure SQL
AI-användningsmetadata (valfritt) Låg Systemgenererat Logg med enbart metadata över AI Assist-anrop: funktion, modell, antal token, anropande användare samt mänskliga beslut om godkännande/avvisning. Prompt- och svarsinnehåll lagras aldrig Azure SQL
Hash-kedjad granskningsliggare Låg-medel Systemgenererat Manipulationssäker liggare med endast tillägg över åtgärder i alla moduler Azure SQL

Personuppgifter som INTE samlas in

AccessPoint samlar inte in eller behandlar: personnummer (Social Insurance Numbers); finansiell information (bankkonton, kreditkort); hälso- eller sjukvårdsjournaler som strukturerad data (de kan förekomma i dokument under granskning); biometriska data; brottsregisterinformation; platsdata; eller cookies/spårningsidentifierare.

Observera: IP-adresser och user agent-strängar registreras endast i begränsade sammanhang (signering av intygande och loggning av dokumentåtkomst) för forensiska granskningsändamål, enligt listan ovan. Allmänt surfbeteende och enhetsfingeravtryck samlas inte in.

Känsliga personuppgifter i dokument

Dokument som samlas in under ATIA-processen kan innehålla vilken kategori av personuppgifter som helst, inklusive känsliga personuppgifter om tredje parter. AccessPoint lagrar, förhandsgranskar och underlättar maskering av dokument, och extraherar — för att stödja granskningsverktygen — varje dokuments klartext till databasen (med valfri OCR av bildbaserade skanningar via en Azure AI Document Intelligence-resurs inom prenumerationen). Den extraherade texten driver innehållssökning (indexeras valfritt i institutionens egen Azure AI Search-resurs), dubblettidentifiering, mönster-/regelbaserade maskeringsförslag och — när den valfria AI Assist-komponenten är driftsatt — maskingenererade förslag och sammanfattningar. All denna bearbetning sker inom institutionens egen Azure-prenumeration, och varje maskinproducerad maskering eller förslag är ett förslag: klassificering och undantag av personuppgifter i dokument beslutas av utbildade SAO:er med hjälp av de inbyggda granskningsverktygen.

Insamling av Microsoft 365-poster (valfritt, styrt av funktionsväxel): en förvaltare kan samla in sina egna Microsoft 365-poster – e-post i Outlook, Outlook-kalender, OneNote, Teams-chattar, Microsoft Lists eller Copilot-interaktionshistorik – som en relevant handling. Insamling använder alltid den inloggade användarens egen delegerade identitet och är begränsad till den användarens egen data (Copilot-hämtning är enbart app-baserad, eftersom ingen delegerad Graph-behörighet finns, men är alltid begränsad server-side till den inloggade användarens eget Entra-objekt-ID – aldrig hela klientorganisationen). Insamlat innehåll återges som en PDF och går in i det normala gransknings-/maskeringsflödet. Kalenderinsamling exkluderar som standard poster märkta Privat/Personligt/Konfidentiellt.

Analys av flöden av personuppgifter

Skede Sammanfattning
Insamling Personuppgifter samlas in enligt ATIA avsnitt 6 (inlämning av förfrågan kräver namn och adress) och Privacy Act avsnitt 4 (insamling relaterad till ett operativt program). Endast personuppgifter som är nödvändiga för att behandla förfrågan samlas in, direkt från den sökande och registrerade av SAO-personal. Fält är konfigurerbara av institutionen.
Användning Den sökandes personuppgifter används uteslutande för att behandla ATIA-/Privacy Act-förfrågan. Endast roller som beviljats behörigheten att visa sökandens personuppgifter (typiskt arketyperna Administratör, SAO och Granskare) kan se den sökandes personuppgifter – Förvaltare och Medarbetare ser dem aldrig (tillämpat server-side genom PII-filtermiddleware). AccessPoint fattar inga automatiserade beslut om individer: den valfria AI Assist-komponenten producerar enbart förslag, redigerbara utkast och skrivskyddade svar, och varje beslut om undantag, maskering, utlämnande och bedömning fattas av utbildad personal. Fasta statistiska rapporter är enbart aggregerade; den anpassade rapportbyggaren exponerar fält på postnivå endast för roller med rapporteringsbehörighet, flaggar synligt personuppgiftsfält i sin katalog, och erbjuder aldrig personuppgiftsfält till AI-funktionen "Fråga AccessPoint".
Utlämnande Svarspaketet tillhandahålls den sökande (ATIA avsnitt 7). Internt utlämnande till personal med rollerna SAO/Granskare är rollstyrt; Förvaltare/Medarbetare får endast sanerade instruktioner. E-post- och Teams-aviseringar till förvaltare/medarbetare innehåller inga personuppgifter om den sökande. Utgivaren tar endast emot klientorganisations-ID, API-version och API:ets egen bas-URL (licensvalidering och identifiering av webbdelen), aviseringsmetadata (mottagarens användar-ID, aktivitetstyp, aktörens visningsnamn, förfrågningsnummer, förhandsgransknings-/ämnestext, referens till relaterad post) och installationsrapporter för jurisdiktionspaket – inga personuppgifter om den sökande. Microsoft behandlar data som underbiträde inom institutionens egen klientorganisation.
Bevarande och gallring En inbyggd funktion för bevarandegranskning tillämpar konfigurerbara bevarandeperioder per posttyp över fem register (förfrågningar, bedömningar, incidenter, klagomål och fristående risker) genom en och samma RetentionService. Radering tar permanent bort posten med dess dokument, uppdrag, uppgifter, intyganden och relaterad historik — omvärderar gallringsbarheten vid raderingstillfället och blockerar poster med ärendeövergripande beroenden — och loggas i tabellen RetentionPurgeLog (som själv aldrig raderas). Azure SQL:s automatiska säkerhetskopior bevarar data i 7–35 dagar beroende på nivå (konfigurerbart långtidsbevarande).
Korrekthet Den sökandes personuppgifter registreras från det ursprungliga förfrågningsformuläret till den återanvändbara kontaktposten för sökande (varje förfrågan länkas till en kontakt); anställdas personuppgifter hämtas från Entra ID och uppdateras vid varje inloggning. Systemet berikar inte poster från externa källor och profilerar inte individer. Det producerar dock härledda representationer av redan innehavt innehåll: extraherad dokumenttext (inklusive valfri OCR), maskinöversättningar av personalens fritextfält (skriver aldrig över en mänsklig översättning), och — när den valfria AI Assist-komponenten är driftsatt — cachade dokumentsammanfattningar samt förslags-/utkastresultat som personalen godkänner eller avvisar.

Aviseringsvägen illustrerar kontrollen "inga personuppgifter om den sökande till utgivaren":

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)

Integritetsriskbedömning

Risk Sannolikhet Påverkan Åtgärd Kvarstående risk
Obehörig åtkomst till den sökandes personuppgifter Låg Medel Detaljerad, behörighetsbaserad RBAC med server-side tillämpning; Förvaltare/Medarbetare arkitektoniskt uteslutna från personuppgifter; Entra ID MFA; behörighetskontroller vid varje förfrågan. Låg
Personuppgiftsincident via dokumentexponering Låg-medel Medel-hög Kryptering i vila (TDE, AES-256); rollbaserad auktorisering; ingen offentlig dokumentåtkomst; maskeringsverktyg tar bort personuppgifter innan paketering av svar. Låg-medel
Personuppgifter i aviseringar Mycket låg Låg Mallar för förvaltare/medarbetare tar automatiskt bort personuppgifter; SAO-aviseringar innehåller förfrågningsnumret men inte den sökandes identitet; Teams-aviseringar innehåller endast aviseringstyp, förfrågningsnummer och uppgifts-/tilldelningsnamn. Mycket låg
Överföring av personuppgifter till utgivaren Mycket låg Låg Utgivaren tar endast emot klientorganisations-ID och API-adress (licensvalidering) samt aviseringsmetadata – inga personuppgifter, dokument eller förfrågningsdetaljer – och har ingen stående åtkomst till institutionens Azure-resurser. Mycket låg
Personuppgifter utanför kanadensisk jurisdiktion Konfigurationsberoende Medel Data lagras i institutionens Azure-prenumeration i den region den väljer (Canada Central/East rekommenderas); Microsoft Cloud Agreement adresserar dataresidens. Institutionen bedömer
Otillräckligt bevarande/otillräcklig gallring Låg-medel Medel Inbyggd bevarandegranskning med konfigurerbara perioder och raderingsloggning; institutionen anpassar scheman till Library and Archives Canadas gallringsbeslut. Låg (med korrekt konfiguration)
Internt hot (missbruk av behörig användare) Låg Medel Omfattande granskningsspår med användarattribuering och tidsstämplar; rollbaserad åtkomst begränsar exponering; administratörer styr rolltilldelningar. Låg

Riskområdespoäng

Enligt TBS:s standardiserade ramverk:

Riskområde Poäng Motivering
Typ av program eller verksamhet 2 Administration av program/verksamhet (ATIA-administration)
Typ av personuppgifter 3 Kontaktuppgifter och potentiellt känsliga handlingar i dokument
Programpartner 2 Microsoft (underbiträde); Realizer (ingen åtkomst till personuppgifter)
Programmets varaktighet 4 Långsiktig/fortlöpande lagstadgad skyldighet
Programpopulation 3 Externa individer som utövar lagstadgade rättigheter
Överföring av personuppgifter 2 Krypterad molninfrastruktur inom kanadensisk jurisdiktion
Teknik och integritet 2 Standardwebbapplikation — ingen övervakning, biometri eller automatiserad profilering. De valfria AI Assist-funktionerna (Azure OpenAI i institutionens egen prenumeration) är enbart förslags-/utkastbaserade — en människa fattar varje beslut, och endast användningsmetadata loggas. Institutioner som driftsätter de valfria AI-komponenterna bör ompröva denna poäng.
Potentiell påverkan på individen 2-3 Möjlig förlägenhet eller ryktesskada om den sökandes identitet avslöjas

Övergripande risknivå: Måttlig — standard för ett administrativt program som behandlar personuppgifter om externa individer, begränsad genom starka tekniska kontroller (kryptering, RBAC, filtrering av personuppgifter, datasuveränitet).

Tekniska och administrativa skyddsåtgärder

Autentisering och åtkomstkontroll

Skyddsåtgärd Implementering
Autentisering Microsoft Entra ID med JWT-bearer-token. Inga lokala användarkonton eller lösenord.
Multifaktorautentisering Tillämpas genom institutionens policyer för Villkorsstyrd åtkomst (Conditional Access) i Entra ID.
Kontinuerlig åtkomstutvärdering Stöds — tokenvalidering sker vid varje API-förfrågan.
Rollbaserad åtkomstkontroll Detaljerade, klientkonfigurerbara behörighetsroller tillämpade server-side på alla API-ändpunkter. Administratör är den enda inbyggda rollen; klientorganisationer definierar roller som motsvarar arketyperna (Request Coordinator, Granskare, Förvaltare, Medarbetare, Läsare), vanligtvis sådda från ett jurisdiktionspaket.
Filtrering av personuppgifter Server-side middleware tar bort den sökandes personuppgifter från svar för varje anropande som inte har behörigheten att visa sökandens personuppgifter; kan inte kringgås av klienten.
Sessionshantering Tokenbaserad; livslängd styrd av Entra ID-policyer.
Bootstrap för första användaren Den första användaren tilldelas rollen Administratör. Inga standard- eller delade autentiseringsuppgifter finns, och en spärr på serversidan förhindrar borttagning av den sista aktiva administratören.

Kryptering

Lager Implementering
Under överföring TLS 1.3 lägst vid App Service-ingången; TLS 1.2+ på Azure SQL och Blob Storage; FTPS inaktiverat.
I vila — databas Azure SQL Transparent Data Encryption (TDE) med Microsoft-hanterade nycklar.
I vila — dokument Azure Blob Storage AES-256-kryptering; kundhanterade nycklar (CMK) tillgängligt.
I vila — hemligheter Azure Key Vault, åtkomst via hanterad identitet.

Nätverkssäkerhet

Skyddsåtgärd Implementering
Enbart HTTPS All HTTP-trafik avvisas; HTTP/2 aktiverat.
CORS Begränsad till institutionens SharePoint-domän.
Hastighetsbegränsning 600 förfrågningar/minut per autentiserad användare.
Säkerhetshuvuden X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, Content-Security-Policy.
Hanteringsplan Grundläggande autentisering för SCM/FTP inaktiverad; hantering enbart via Azure-portalen med Entra ID + MFA.

Övervakning och granskning

Skyddsåtgärd Implementering
Applikationens granskningsspår Alla skapa-/uppdatera-/ta bort-åtgärder registreras med användar-ID, tidsstämpel, ändrat fält samt gamla/nya värden.
Manipulationssäker granskningsliggare En hash-kedjad (SHA-256) liggare med endast tillägg registrerar åtgärder över alla moduler; integriteten kan verifieras server-side, och en domstolsklar ärenderevisionsexport (tidigare kallad "bevispaket") kan genereras för en förfrågan.
Logg för dokumentåtkomst Förhandsgransknings- och nedladdningshändelser registreras med användar-ID, tidsstämpel, IP-adress och user agent. Endast infogning.
Raderingslogg för bevarande Alla raderingsåtgärder registreras med användarattribuering.
Applikationsövervakning Azure Application Insights registrerar HTTP-förfrågningar, undantag och beroendeanrop (90 dagars kvarhållning).
Larmregler Konfigurerbara mätvärdeslarm för HTTP 5xx-fel och hög latens.
Log Analytics Centraliserad logglagring med KQL-frågemöjlighet för säkerhetsutredningar.

Administrativa skyddsåtgärder

Administratörer tilldelar roller via Inställningar; rolländringar träder i kraft omedelbart. En Application Access Policy begränsar Mail.Send till enbart den avsedda delade brevlådan. Konfigurationsändringar tillämpas via versionerade jurisdiktionspaket med granskningsloggning av installationer. Personalutbildning, policy för acceptabel användning och rutiner för hantering av personuppgiftsincidenter fastställs av institutionen.

Tredjepartstjänster och datadelning

Tjänst Roll Mottagna personuppgifter Dataplats
Microsoft Azure Underbiträde (IaaS: App Service, SQL, Blob, Key Vault, Application Insights) All applikationsdata Institutionens Azure-region
Microsoft 365 Personuppgiftsbiträde (Graph Mail.Send, Teams aktivitetsflöde) och, valfritt, en källa för poster insamlade av förvaltare Innehåll i e-post-/Teams-aviseringar; vid valfri insamling, förvaltarens eget M365-innehåll Institutionens M365-klientorganisation
Realizer Services (utgivare) Programvaruutgivare — ingen roll som personuppgiftsbiträde för kundens personuppgifter Inga — enbart klientorganisations-ID + aviseringsmetadata + installationsrapporter för jurisdiktionspaket Utgivarens Azure (Kanada)
Syncfusion Inbäddat bibliotek (inte en tjänst) Inga — konvertering sker inom institutionens App Service Institutionens App Service
Azure AI Search (valfritt) Institutionsdriftsatt resurs — index för innehållssökning Dokumentmetadata, extraherad text och innehållsinbäddningar Institutionens Azure-prenumeration
Azure OpenAI (valfritt — AI Assist) Institutionsdriftsatt resurs — förslag, utkast, sammanfattningar, översättning Avgränsade utdrag ur ärendeposter och extraherad dokumenttext vid anropstillfället Institutionens Azure-prenumeration
Azure AI Document Intelligence (valfritt — OCR) Institutionsdriftsatt resurs — text från skannade dokument Dokumentsidor som skickas för prebuilt-read-analys Institutionens Azure-prenumeration

Valfria Azure AI-tjänster. De tre AI-resurserna ovan är inte utgivartjänster: var och en driftsätts i institutionens egen prenumeration och region, autentiserar enbart med App Service hanterade identitet (API-nyckelåtkomst inaktiverad), och skickar ingenting till Realizer Services. Varje AI-utdata är ett förslag, ett redigerbart utkast eller ett skrivskyddat svar — personalen beslutar; reglage per funktion och klientorganisation samt en månatlig tokenbudget (som helt stoppar all AI-bearbetning) ger styrning; Microsoft tränar inte modeller på datat; och AccessPoint lagrar endast anropsmetadata, aldrig prompt- eller svarsinnehåll. Var Azure OpenAI:s inferens bearbetas beror på den driftsättningstyp som väljs vid driftsättningen (global eller EU-/US-datazon) — institutioner bör bekräfta valet mot sina residenskrav. Ärenderevisionsexporter som genereras för en förfrågan innehåller en redovisning av AI-inblandning (endast metadata), och samma information är synlig i varje posts aktivitetsflöde.

Viktig poäng: Inga personuppgifter om den sökande, inget dokumentinnehåll eller några förfrågningsdetaljer överförs till Realizer Services eller någon extern part. All dokumentkonvertering och maskeringsbehandling sker inom institutionens egen App Service, och den valfria sök-, OCR- och AI-bearbetningen sker inom institutionens egen Azure-prenumeration.

Tillämpliga personuppgiftsbanker

PIB Registreringsnummer Beskrivning
Access to Information Act and Privacy Act Requests PSU 901 Poster relaterade till ATIP-förfrågningar
Employee Personnel Records PSE 901 Anställdas namn och roller i granskningsspåret

Institutioner bör bekräfta tillämpliga PIB:er och huruvida nya PIB:er krävs för deras specifika distribution.

Tillgänglighet av den fullständiga PIA:n

Den fullständiga integritetskonsekvensbedömningen – inklusive den kompletta inventeringen av personuppgifter, detaljerad analys av insamling/användning/utlämnande/bevarande/korrekthet, rättslig grund och dataflödesdiagram – finns tillgänglig för kunder och potentiella kunder på begäran. Implementerande institutioner använder den som den tekniska och arkitektoniska grunden för sin egen PIA, och fyller i den institutionella översikten, bevarandescheman, avtal om informationsdelning och godkännande innan de lämnar in den till TBS och Office of the Privacy Commissioner.