Bedömning av integritetsrisker för ISO 27701 och GDPR

Måndagsmorgonens möte kändes välbekant för Maria, informationssäkerhetschef på ett snabbväxande hälsoteknikbolag.

VD:n ville ha en enkel instrumentpanel som visade riskexponeringen enligt GDPR innan bolaget lanserade sin AI-drivna plattform för patientanalys. Den nya dataskyddsansvariga, David, hade ett register över behandlingsaktiviteter (RoPA) med 50 flikar. Utvecklingsteamet hade säkrat molnmiljön. Produktteamet var redo att gå i produktion. Leverantören beskrev sin kedja av underbiträden som ”i företagsklass”.

Men en fråga fick rummet att stanna upp.

”Vilken är vår faktiska risk, och kan vi visa företagskunder att vi har den under kontroll?”

RoPA visade vad bolaget behandlade. Säkerhetsriskregistret visade infrastrukturrisker. Några DPIA:er låg i separata dokument. Leverantörsgranskningarna fanns i upphandlingsmappar. Ingen kunde visa en spårbar beslutskedja från behandlingsaktivitet till integritetsrisk, DPIA-beslut, riskbehandlingsplan, kontrollmappning, godkännande av kvarstående risk och granskningsdatum.

Det är den lucka många organisationer möter när de rör sig mot ISO/IEC 27701:2025 och ansvarsskyldighet enligt GDPR. De har integritetsmeddelanden, leverantörsfrågeformulär, RoPA-poster, dataflödeskartor, DPIA-mallar och ISO/IEC 27001:2022-kontroller. Det de ofta saknar är det operativa lager som binder samman allt.

Ett moget ledningssystem för integritetsinformation, PIMS, behandlar inte bedömning av integritetsrisker som ett juridiskt sidodokument. Det behandlar den som ett repeterbart beslutsarbetsflöde: identifiera behandlingen, screena risken, avgöra om en DPIA krävs, välja kontroller, tilldela ägare, godkänna kvarstående risk, övervaka utlösande händelser och bevara underlag.

Det är där Clarysecs policypaket, Zenith Blueprint och Zenith Controls hjälper team att gå från frikopplade kalkylblad till en försvarbar motor för integritetsrisker.

Bedömning av integritetsrisker är det saknade operativa lagret

Ansvarsskyldighet enligt GDPR reduceras ofta till att ”ha dokumentation”. Dokumentation är viktig, men artikel 5(2) går längre. Den personuppgiftsansvariga ansvarar för, och ska kunna visa, efterlevnad av principerna i artikel 5(1), inklusive laglighet, korrekthet, öppenhet, ändamålsbegränsning, uppgiftsminimering, riktighet, lagringsminimering, integritet och konfidentialitet.

Det kräver mer än en RoPA. Organisationen måste kunna förklara varför en behandlingsaktivitet är godtagbar, vilka risker den medför för enskilda personer, vilka kontroller som reducerar riskerna, vem som äger beslutet och när det ska granskas.

ISO/IEC 27701:2025 förstärker denna förväntan genom att bädda in dataskyddsstyrning i ett styrt PIMS. I praktiken måste bedömning av integritetsrisker koppla samman sex operativa objekt:

1. Förteckningen över PII-behandling eller RoPA.
2. Dokumentation av rättslig grund och ändamål.
3. Screening av integritetsrisker och DPIA-beslut.
4. Riskbehandling och val av kontroller.
5. Styrning av leverantörer, personuppgiftsbiträden och underbiträden.
6. Underlag som bevaras i ISMS och PIMS.

Clarysec gör den kopplingen explicit. I Enterprise Policy för bedömning av integritetsrisker och DPIA utlöses processen innan behandlingen påbörjas:

[Båda] Processägaren / verksamhetsägaren ska initiera screening av integritetsrisker i REG04 innan ny eller väsentligt ändrad PII-behandling som registrerats i REG02 påbörjas.

Samma uppströmsdisciplin finns i Enterprise Policy för PII-behandlingsförteckning och rättslig grund:

[Båda] Processägaren / verksamhetsägaren ska initiera screening av integritetsrisker och DPIA i REG04 innan ny eller väsentligt ändrad PII-behandling går vidare.

Det förhindrar ett vanligt bristmönster: produkten lanseras, RoPA uppdateras i efterhand, DPIA-frågan kommer för sent och riskregistret fångar aldrig integritetsscenariot.

För personuppgiftsansvariga stöder detta disciplin kring rättslig grund enligt GDPR artikel 6, inbyggt dataskydd och dataskydd som standard enligt artikel 25, säkerhet i samband med behandlingen enligt artikel 32 och ansvarsskyldighet enligt artikel 5. För personuppgiftsbiträden stöder det dokumenterade instruktioner, kundförsäkran, avtalsgränser och transparens kring underbiträden.

Utgå från faktisk behandling, inte en tom mall

En bedömning av integritetsrisker misslyckas när den börjar med ett tomt formulär och saknar operativ kontext. Den första frågan bör inte vara ”Behöver vi en DPIA?” Den bör vara ”Vilken behandling förändras faktiskt?”

För en SaaS-, fintech- eller hälsoteknikorganisation kan förändringen omfatta:

• En ny datakategori, exempelvis beteendebaserade användningsdata, hälsodata, biometriska signaler eller betalningsmetadata.
• Ett nytt ändamål, exempelvis bedrägeripoängsättning, patientanalys, AI-stödd support, churn-prognoser eller personalisering.
• En ny mottagare, ett nytt personuppgiftsbiträde eller ett nytt underbiträde.
• Ett nytt supportarbetsflöde eller en ny väg för gränsöverskridande åtkomst.
• En ny bevarandetid.
• En ny modell, algoritm eller automatiserad rekommendation.
• En ny grupp registrerade, exempelvis minderåriga, anställda, patienter eller ekonomiskt sårbara personer.

GDPR:s definitioner är breda. Personuppgifter omfattar identifierare, onlineidentifierare, lokaliseringsuppgifter och faktorer kopplade till identitet. Behandling omfattar insamling, lagring, hämtning, användning, utlämnande, begränsning, radering och förstöring. En personuppgiftsincident omfattar oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande eller obehörig åtkomst.

Det innebär att ett arbetsflöde för integritetsrisker måste fånga mer än om databasen är krypterad. Det måste fånga varför behandlingen finns, om ändamålet är förenligt, om den rättsliga grunden är giltig, om känsliga personuppgifter behandlas, om enskilda kan förstå behandlingen och om skyddsåtgärderna är proportionerliga.

För mindre team ger SME Policy för dataskydd och integritet startpunkten i klausul 5.2.1:

Integritetssamordnaren ska upprätthålla ett register över alla behandlingsaktiviteter för personuppgifter, inklusive datakategorier, ändamål, rättslig grund och bevarandetider

Det registret är inte pappersarbete. Det är indatamodellen för bedömning av integritetsrisker. Utan datakategorier, ändamål, rättslig grund och bevarandetider kan bedömningen inte tillförlitligt utvärdera ändamålsbegränsning, uppgiftsminimering, lagringsminimering, öppenhet eller riktighet.

Samma SME-policy gör också riskgranskning till en återkommande skyldighet i klausul 7.1.1:

Integritetssamordnaren ska bedöma integritetsrisker årligen och vid större systemändringar

För större organisationer är styrningskadensen starkare. Enterprise Policy för dataskydd och integritet anger:

Integritetsriskregister ska upprätthållas inom ISMS och granskas minst kvartalsvis av dataskyddsombudet (DPO) och informationssäkerhetschefen.

Det är här integrationen mellan ISO/IEC 27701:2025 och ISO/IEC 27001:2022 blir praktisk. Integritetsrisker göms inte i juridiska mappar. De granskas tillsammans med säkerhetsrisker, leverantörsrisker, incidenter, revisionsiakttagelser, riskbehandlingsplaner och ledningsrapportering.

Clarysecs arbetsflöde från REG02 till REG04

Den mest effektiva processen för bedömning av integritetsrisker är tillräckligt enkel för verksamhetsägare och tillräckligt robust för revisorer. Clarysecs modell använder REG02 som förteckning över PII-behandling och REG04 som post för bedömning av integritetsrisker och DPIA.

Policy för bedömning av integritetsrisker och DPIA definierar det minsta underlag som krävs innan REG04 kan stängas:

[Båda] Dataskyddsansvarig / PIMS-ansvarig ska säkerställa att varje REG04-bedömning dokumenterar riskklassning, riskbehandlingsbeslut, ägare, förfallodatum, kvarstående risk, godkännandestatus och granskningsdatum före stängning.

Den meningen är den operativa ryggraden. En bedömning av integritetsrisker är inte stängd för att någon skrev ”låg risk” i en kommentarsruta. Den är stängd när posten innehåller klassning, riskbehandlingsbeslut, ägare, förfallodatum, kvarstående risk, godkännandestatus och granskningsdatum.

För små och medelstora företag skalas samma disciplin ned. SME Riskhanteringspolicy anger:

Varje riskpost ska innehålla: beskrivning, sannolikhet, konsekvens, poäng, ägare och riskbehandlingsplan.

Principen är proportionalitet, inte informalitet. Mindre organisationer kan använda ett enklare register, men varje risk behöver fortfarande en beskrivning, poäng, ägare och riskbehandlingsplan.

Använd riskmotorn i ISO/IEC 27001:2022 för integritet

Integritetsrisk bör inte ligga utanför organisationens riskhanteringsmetod. ISO/IEC 27001:2022 tillhandahåller redan ledningssystemets motor: kontext, intressenter, omfattning, ledarskap, riskbedömning, riskbehandling, operativ styrning, dokumenterad information, utvärdering av prestanda och ständig förbättring.

Klausulerna 4.1 till 4.4 kräver att organisationen förstår interna och externa frågor, intressentkrav, ISMS-omfattning och ISMS-processer. För integritet omfattar intressenter kunder, registrerade, anställda, tillsynsmyndigheter, personuppgiftsbiträden, underbiträden, dataskyddsmyndigheter, tillsynsmyndigheter inom finanssektorn där det är relevant och avtalskunder.

Klausul 6.1.2 kräver en process för riskbedömning av informationssäkerhet. Klausul 6.1.3 kräver riskbehandling av informationssäkerhet, inklusive val av kontroller, framtagning av en tillämpbarhetsförklaring, formulering av en riskbehandlingsplan och riskägarens godkännande av planen och de kvarstående riskerna. Klausulerna 8.2 och 8.3 kräver att riskbedömningar och riskbehandlingar av informationssäkerhet utförs med planerade intervall eller när betydande förändringar sker, samtidigt som dokumenterade resultat bevaras.

Clarysecs Enterprise Riskhanteringspolicy är anpassad till denna struktur i klausul 5.1:

En formell riskhanteringsprocess ska upprätthållas i enlighet med ISO/IEC 27005 och ISO 31000 och omfatta riskidentifiering, riskanalys, riskutvärdering, riskbehandling, riskövervakning och riskkommunikation.

För integritet måste riskkriterierna omfatta påverkan på enskilda personer, inte bara verksamhetspåverkan. En låg finansiell förlust kan fortfarande innebära hög integritetspåverkan om behandlingen omfattar känsliga personuppgifter, sårbara personer, profilering, bristande transparens, olagligt bevarande, oförmåga att utöva rättigheter eller immateriell skada.

Clarysecs Zenith Blueprint: en revisors färdplan i 30 steg förklarar detta i riskhanteringsfasen, steg 10:

När konsekvens definieras är det klokt att relatera nivåerna till den egna verksamhetens skala. Exempelvis kan ”större finansiell påverkan = förlust > 100 000 USD” (anpassa till er kontext). Beakta även regulatorisk påverkan: exempelvis kan en personuppgiftsincident automatiskt vara ”större” eller ”allvarlig” på grund av GDPR-sanktionsavgifter och anmälningskrav, även om den direkta finansiella förlusten är oklar.

Den vägledningen är särskilt viktig för AI-analys, hälsodata, finansiell profilering, övervakning av anställda och kundpoängsättning. Skadan kan vara rättslig, anseenderelaterad, diskriminerande, operativ, avtalsmässig eller personlig.

Ett praktiskt exempel: AI-baserad patientanalys

Återgå till Maria och David. Deras hälsoteknikplattform kommer att behandla känsliga hälsouppgifter enligt GDPR artikel 9. Den kommer att använda patienthistorik, bokningsuppgifter, kliniska anteckningar och modellutdata för att generera riskinsikter.

Med Zenith Blueprint börjar de med steg 9 och identifierar tillgångar, hot och sårbarheter:

För varje tillgång, registrera nyckeluppgifter: namn/beskrivning, ägare, plats och klassificering (känslighet). En tillgång kan exempelvis vara ”kunddatabas – ägs av IT-avdelningen – driftad på AWS – innehåller personuppgifter och finansiella uppgifter (hög känslighet).”

Samma steg lägger till integritetsperspektivet:

Säkerställ att tillgångar med personuppgifter flaggas (för GDPR-relevans) och att kritiska tjänstetillgångar markeras (för möjlig NIS2-tillämplighet om ni verkar i en reglerad sektor).

Marias team identifierar AI-plattformen för patientanalys, patientdatabasen, datalagret, pipelinen för modellträning, klinikerns instrumentpanel, molnlagring, identitetsleverantören, revisionsloggar, supportärendeplattformen och det tredjepartsbaserade analysverktyget. Varje tillgång får en ägare, plats, klassificering och relation till PII.

Därefter definierar de riskscenarier. Ett är obehörig åtkomst till patientjournaler. Ett annat är oavsiktligt röjande genom analysutdrag. Ett tredje är bias i AI-modellen på grund av skeva träningsdata, vilket leder till orättvis eller diskriminerande riskpoängsättning av patienter.

Steg 11 i Zenith Blueprint förklarar riskregistrets roll:

Riskregistret är typiskt ett kalkylblad (vår mall “Risk Register and SoA Builder.xlsx” har ett särskilt blad för detta). Det fungerar som huvudlogg för risker.

En integritetsriskpost för scenariot med bias i AI-modellen kan se ut så här:

Denna post gör det som det gamla kalkylbladet inte kunde. Den kopplar en behandlingsaktivitet till en tillgång, ett hot, en sårbarhet, risk för enskilda personer, ägare, poäng, riskbehandlingsplan och underlagsspår.

Eftersom behandlingen är hög risk och omfattar känsliga personuppgifter blir DPIA:n inte en separat efterhandsåtgärd. Den blir det fördjupade bedömningssteget för en risk som redan är registrerad i systemet. Enterprise Policy för dataskydd och integritet anger:

Alla betydande ändringar av system eller processer som innefattar personuppgifter (PII) ska kräva en dokumenterad konsekvensbedömning avseende dataskydd (DPIA), granskad av dataskyddsombudet (DPO).

För hög kvarstående risk hos personuppgiftsansvarig tillägger Policy för bedömning av integritetsrisker och DPIA:

[Personuppgiftsansvarig] Högsta ledningen ska godkänna acceptans av hög kvarstående integritetsrisk i REG04 innan högriskbehandling som personuppgiftsansvarig påbörjas eller fortsätter.

Lanseringsbeslutet är nu spårbart: vad som ändrades, vad som bedömdes, vilka risker som identifierades, vilka kontroller som valdes, vem som äger riskbehandlingen, vem som godkände kvarstående risk och när beslutet ska granskas.

Från risker till kontroller med Zenith Controls

Bedömning av integritetsrisker är bara meningsfull om den leder till kontrollbeslut. Clarysecs Zenith Controls: vägledning för mappning mellan efterlevnadskrav är en vägledning som kopplar ISO/IEC 27001:2022- och ISO/IEC 27002:2022-kontroller till relaterade krav i olika ramverk. Det är inte en separat kontrolluppsättning. Den hjälper team att förstå hur kontrollunderlag stöder flera skyldigheter.

För bedömning av integritetsrisker lyfter Zenith Controls fram tre centrala ISO/IEC 27002:2022-kontroller:

Kontroll 5.34 stöder också GDPR artikel 25 och artikel 32, NIS2 artikel 21 om åtgärder för hantering av cybersäkerhetsrisker, DORA:s förväntningar på IKT-riskhantering och utfall i NIST CSF 2.0 såsom GV.OC-03 för rättsliga, regulatoriska, avtalsmässiga, integritetsrelaterade och medborgerliga fri- och rättighetsskyldigheter, samt PR.DS-01 för skydd av data i vila.

Steg 13 i Zenith Blueprint kopplar dessa beslut till tillämpbarhetsförklaringen:

Korsreferera regelverk: Om vissa kontroller införs specifikt för att uppfylla GDPR, NIS2 eller DORA kan ni notera det antingen i riskregistret (som del av motiveringen av riskpåverkan) eller i SoA-anteckningarna.

Det är så en integritetsiakttagelse blir ett kontrollbeslut i ISMS och PIMS, inte bara en juridisk kommentar.

Leverantörs- och biträdesrisk ska bedömas före godkännande

Många integritetsbrister börjar i leverantörsstyrningen. Ett personuppgiftsbiträde lägger till ett nytt underbiträde. En supportleverantör får produktionsåtkomst. En analysplattform lagrar händelsedata i en ny region. Upphandling undertecknar avtalet innan dataskyddsfunktionen ser risken.

Clarysecs Enterprise Policy för hantering av personuppgiftsbiträden, underbiträden och tredjepartsintegritet förhindrar detta genom att koppla samman leverantörsgranskning, REG04 och tredjepartsregistret:

[Båda] Dataskyddsansvarig / PIMS-ansvarig ska utlösa screening av integritetsrisker och DPIA i REG04 för relationer med personuppgiftsbiträden med hög risk och väsentliga integritetsrelaterade tredjepartsändringar före godkännande, och REG04-referensen ska registreras i REG08.

För små och medelstora företag fastställer Policy för leverantörssäkerhet och tredjepartssäkerhet kravet på granskning före uppdrag:

Före uppdrag ska varje leverantör granskas avseende potentiella risker. Denna granskning ska omfatta:

Det operativa budskapet är tydligt. Leverantörsrisk bedöms före godkännande, inte efter underskrift.

Detta stöder också NIS2 och DORA. NIS2 artikel 21 kräver säkerhet i leveranskedjan som del av åtgärderna för hantering av cybersäkerhetsrisker. DORA artiklarna 28 till 30 kräver att finansiella entiteter hanterar IKT-tredjepartsrisk, utför förhandsbedömningar före avtal, upprätthåller avtalsmässiga skyddsåtgärder, förstår risker i underleverantörsled, övervakar beroenden och planerar exit för kritiska eller viktiga funktioner.

Om en leverantör hanterar PII eller stöder integritetskritisk behandling bör integritetsriskposten visa leverantören, behandlingsrollen, dataplats, beroende av underbiträden, avtalsmässiga skyddsåtgärder, incidentåtaganden, bevaranderegler, övervakningsmetod och exitplan.

Ett arbetsflöde, många efterlevnadsutfall

Fördelen med ett integrerat PIMS-arbetsflöde är att samma underlag stöder flera ramverk utan dubbelarbete.

NIST CSF 2.0 är särskilt användbart för kommunikation med ledningen. Dess GOVERN-funktion omfattar organisatorisk kontext, riskhanteringsstrategi, policy, roller, tillsyn och risker i leveranskedjan. Dess organisationsprofiler hjälper till att översätta nuvarande och önskade utfall till en prioriterad åtgärdsplan, exempelvis ett riskregister eller en åtgärds- och milstolpeplan.

För organisationer som omfattas av NIS2, DORA eller sektorsspecifika regler stöder underlag om integritetsrisker även cybersäkerhetsstyrning, leverantörstillsyn, incidentberedskap och resiliensrapportering.

Riskbehandling av integritetsrisker är bredare än kryptering

Kryptering är viktigt, men det kan inte åtgärda en ogiltig rättslig grund, överdriven insamling, icke redovisad profilering, otillbörlig behandling, olagligt bevarande eller ett personuppgiftsbiträde som agerar utanför instruktionerna.

SME Policy för dataskydd och integritet anger:

Kontroller ska införas för att reducera identifierade risker, inklusive kryptering, anonymisering, säker avveckling och åtkomstbegränsningar

Detta är starka exempel, men riskbehandlingen måste passa scenariot. En riskbehandlingsplan för integritetsrisker kan omfatta att begränsa behandlingens ändamål, ta bort onödiga datakategorier, aggregera eller pseudonymisera data, uppdatera integritetsmeddelanden, ändra rättslig grund där det är lämpligt, begränsa bevarande, begränsa åtkomst, lägga till loggning, uppdatera avtal, slutföra en DPIA, skjuta upp lansering eller avvisa behandling som förblir oacceptabel.

Enterprise Riskhanteringspolicy förstärker riskbehandlingsplanering för risker över toleransnivån:

Alla risker som klassificeras över toleransnivån ska ha en tillhörande riskbehandlingsplan som anger:

I praktiken innebär detta att hög integritetsrisk inte kan accepteras genom tystnad. Den ska behandlas, överföras där det är lämpligt, undvikas eller formellt accepteras av rätt ansvarig ägare.

Utlösare för granskning håller bedömningen levande

En bedömning av integritetsrisker som aldrig återbesöks blir inaktuellt underlag. ISO/IEC 27001:2022-klausulerna 8.2 och 8.3 kräver riskbedömning och riskbehandling med planerade intervall eller när betydande förändringar sker. Ansvarsskyldighet enligt GDPR förutsätter aktuella beslut. ISO/IEC 27701:2025 är beroende av övervakning och ständig förbättring.

En REG04-bedömning bör öppnas på nytt när ändamålet ändras, nya datakategorier läggs till, känsliga personuppgifter börjar behandlas, rättslig grund ändras, ett personuppgiftsbiträde eller underbiträde ändras, lagring flyttas till en ny region, bevarandetider ändras, profileringslogik ändras, en incident eller nära händelse inträffar, kundavtal ändras eller en ny skyldighet enligt NIS2, DORA eller sektorsspecifika regler blir tillämplig.

Incidentprocesser bör återföra information till arbetsflödet för integritetsrisker. NIS2 artikel 23 fastställer stegvis rapportering av betydande incidenter. DORA artiklarna 17 till 20 kräver registrering, klassificering, eskalering, kommunikation, rotorsaksanalys och förbättring av IKT-relaterade incidenter. GDPR:s skyldigheter vid personuppgiftsincident kan också utlösas. Om en incident visar svaga åtkomstkontroller, överdrivet bevarande, otydlig leverantörsavisering eller bristfälliga kundinstruktioner ska REG04 uppdateras.

Vad revisorer förväntar sig att se

Ett starkt arbetsflöde för integritetsrisker bör hålla för flera granskningsperspektiv.

Enterprise Policy för dataskydd och integritet kräver också internrevisionsaktivitet:

En intern integritetsrevision ska genomföras årligen eller vid större organisatoriska eller regulatoriska förändringar. Revisionens omfattning ska inkludera:

Det skapar en återkopplingsslinga till ledningen. Är REG02-posterna kompletta? Genomförs REG04-screeningar i tid? Genomförs DPIA:er när det krävs? Godkänns höga kvarstående risker? Fångas leverantörsändringar? Stängs riskbehandlingsplaner? Är integritetsmeddelanden anpassade till faktisk behandling?

Checklista för nästa möte om integritetsrelaterad förändring

Använd denna checklista innan en ny behandlingsaktivitet, produktfunktion, leverantör, modell eller supportarbetsflöde tas i produktion.

Denna checklista ersätter inte policy. Den är ett praktiskt sätt att operationalisera policy i möten med produkt, upphandling, utveckling, regelefterlevnad, juridik och ledning.

Gör ansvarsskyldighet för integritet till ett fungerande system

ISO/IEC 27701:2025 och ansvarsskyldighet enligt GDPR kräver mer än dokument. De kräver ett fungerande system som kopplar samman behandlingsposter, rättslig grund, integritetsrisk, DPIA-beslut, leverantörer, kontroller, ägare, godkännanden och underlag.

Börja med riskhanteringsfasen i Zenith Blueprint, särskilt steg 9 till 13. Använd Risk Register and SoA Builder för att koppla samman tillgångar, hot, sårbarheter, integritetsrisker, riskbehandlingsbeslut och kontrollreferenser. Använd därefter Zenith Controls för att mappa PII-skydd, tillgångsförteckning och leverantörssäkerhet till förväntningar på bestyrkande enligt GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 och COBIT 19.

Samordna de operativa policyer som gör arbetsflödet bindande: Policy för bedömning av integritetsrisker och DPIA, Policy för PII-behandlingsförteckning och rättslig grund, Policy för hantering av personuppgiftsbiträden, underbiträden och tredjepartsintegritet, Riskhanteringspolicy och Policy för dataskydd och integritet. Mindre team kan också använda Clarysecs SME-policyer, medan större organisationer kan strukturera styrningen genom Enterprise-policyer.

Om ditt team lanserar ny behandling, byter leverantörer, förbereder sig för ISO/IEC 27701:2025 eller försöker göra underlag för ansvarsskyldighet enligt GDPR repeterbart, börja med en aktiv behandlingsaktivitet. Öppna REG02, kör REG04-screening, mappa riskerna till kontroller, tilldela ägare för riskbehandling och granska kvarstående risk med rätt beslutsfattare.

Det är i detta arbetsflöde som dataskyddsstyrning blir operativ.