Styrning av gemensamt personuppgiftsansvar: revisionsguide för artikel 26 i GDPR

Samtalet kom en tisdagsmorgon. För CareConnects informationssäkerhetschef, hos en snabbväxande medicinteknisk SaaS-leverantör, var det ögonblicket då förutsättningarna förändrades.

I andra änden fanns regelefterlevnadsansvarig på MetroHealth, deras viktigaste sjukhuspartner. En patient som använde deras gemensamt hanterade plattform för fjärrövervakning hade lämnat in en begäran om tillgång till personuppgifter en månad tidigare. Ingen av organisationerna hade svarat fullständigt. Var och en trodde att den andra ansvarade.

Därefter vidarebefordrade juridikfunktionen ett andra meddelande. En junior utvecklare på CareConnect hade av misstag exponerat en icke-kritisk API-slutpunkt som innehöll begränsade patientidentifierare. Problemet verkade kunna avgränsas, och GDPR:s 72-timmarsfrist för anmälan av personuppgiftsincident hade ännu inte löpt ut. Men samma fråga låste båda teamen.

Vem informerar tillsynsmyndigheten? Vem kommunicerar med patienterna? Vem äger informationen till registrerade? Vem validerar den registrerades begäran? Vem registrerar beslutet?

Det kommersiella avtalet var detaljerat om servicekrediter, fakturering, ansvarsbegränsningar och milstolpar i produktplanen. Det sade nästan ingenting om den operativa verkligheten i styrning av gemensamt personuppgiftsansvar enligt artikel 26 i GDPR.

Det är här många partnerskap brister. Problemet är inte att dataskydds-, juridik-, säkerhets- och upphandlingsteam aldrig har hört uttrycket ”arrangemang för gemensamt personuppgiftsansvar”. Problemet är att ingen, innan behandlingen börjar, kan visa vem som ansvarar för transparens, rättslig grund, registrerades rättigheter, eskalering av personuppgiftsincidenter, vidareförda skyldigheter till leverantörer, överföringar, lagringstid, underlag och kommunikation med tillsynsmyndighet.

GDPR definierar skyldigheten. ISO/IEC 27701:2025 ger dataskyddsteam en ledningssystemstruktur. Clarysecs PIMS-policyer, Zenith Blueprint: en revisors färdplan i 30 steg och Zenith Controls: guiden för mappning mellan efterlevnadskrav omvandlar artikel 26 till revisionsklart operativt underlag.

Varför styrning av gemensamt personuppgiftsansvar brister innan någon märker det

En relation med gemensamt personuppgiftsansvar finns när två eller flera parter gemensamt fastställer ändamålen med och medlen för behandling av personuppgifter. Det avgörande är inte avtalets formulering. Det är beslutsinflytandet.

I exemplet med CareConnect och MetroHealth tillhandahåller CareConnect plattformen, analysfunktionerna, den tekniska arkitekturen, användargränssnittet och dataflödena. MetroHealth tillhandahåller patientrelationen, den kliniska kontexten, tjänstemodellen och patientdata. Båda påverkar varför personuppgifter behandlas och hur behandlingen fungerar. Det skiljer sig tydligt från en leverantör som endast driftar en databas eller skickar meddelanden enligt dokumenterade instruktioner.

Samma mönster uppstår i kampanjer för finansiell hälsa, inbäddade försäkringspartnerskap, onlinemarknadsplatser, konsortier för bedrägeridetektering, uppkopplade hälsoplattformar, lojalitetsprogram, ekosystem för identitetsverifiering och analyssamarbeten. En bank, ett försäkringsbolag och en SaaS-plattform kan gemensamt besluta om målsegment, regler för profilering, konverteringsmått och marknadsföringskanaler. Ett personuppgiftsbiträdesavtal löser inte problemet om parterna i praktiken är gemensamt personuppgiftsansvariga.

De praktiska bristerna är förutsägbara:

1. Informationen till registrerade säger inte mycket mer än ”vi kan dela data med partner”.
2. Behandlingsförteckningen identifierar parter men inte ansvarsfördelningen.
3. Arbetsflödet för registrerades rättigheter saknar väg för vidarebefordran, validering eller svar på begäranden.
4. Incidentplanen säger ”underrätta juridikfunktionen” men inte vilken gemensamt personuppgiftsansvarig som leder extern kommunikation.
5. Avtalet behandlas som kommersiell dokumentation, inte som underlag för ansvarsskyldighet.
6. Avslutsklausuler omfattar inte återlämning av data, radering, anonymisering, borttagning av åtkomst eller bevarande av underlag.

Artikel 5 i GDPR gör dessa brister revisionskänsliga eftersom personuppgiftsansvariga inte bara ska följa principer som laglighet, korrekthet, transparens, ändamålsbegränsning, uppgiftsminimering, riktighet, lagringsminimering, integritet och konfidentialitet samt ansvarsskyldighet. De måste också kunna visa efterlevnad. Artikel 6 lägger till kravet på rättslig grund. Artikel 3 kan föra in SaaS-, fintech-, healthtech- och analysleverantörer utanför EU i tillämpningsområdet när de erbjuder tjänster till personer i EU eller övervakar deras beteende.

Lärdomen för CISO:er och regelefterlevnadsansvariga är tydlig: styrning av gemensamt personuppgiftsansvar är inte ”bara juridik”. Det är ett tvärfunktionellt kontrollsystem som omfattar dataskydd, säkerhet, upphandling, produkt, teknik, support, incidentrespons, marknadsföring och ledningens tillsyn.

PIMS-principen i ISO/IEC 27701:2025: besluta innan behandlingen börjar

Ett ledningssystem för hantering av integritetsinformation enligt ISO/IEC 27701:2025 fungerar endast om dataskyddsroller fastställs innan behandlingen börjar. Det är den operativa disciplin som förhindrar att artikel 26 blir en rekonstruktion efter en incident.

Clarysecs policy för ledningssystem för hantering av integritetsinformation, klausul 4.2.2, anger:

[Gemensamt personuppgiftsansvar] Leverantörs-/upphandlingsansvarig SKA dokumentera ansvarsfördelningen för gemensamt personuppgiftsansvar i REG08 innan gemensam behandling påbörjas.

Formuleringen ”innan gemensam behandling påbörjas” är kontrollpunkten. Det betyder innan plattformsintegrationen tas i produktion, innan den delade kontrollpanelen aktiveras, innan CRM-synkronisering startar, innan kampanjmålgrupper aktiveras och innan registrerades begäranden börjar komma in.

Den stödjande skyldigheten för behandlingsförteckningen finns i policy för behandlingsförteckning och rättslig grund för PII, klausul 4.3.5:

[Gemensamt personuppgiftsansvar] Leverantörs-/upphandlingsansvarig SKA registrera behandlingsändamålet för gemensamt personuppgiftsansvar och referensen till ansvarsfördelningen i REG02 och REG08 innan behandling under gemensamt personuppgiftsansvar påbörjas.

Tillsammans skapar dessa klausuler den underlagskedja som revisorer förväntar sig:

• REG02 registrerar behandlingsaktiviteten, ändamål, kategorier av personuppgifter, rättslig grund, lagringstid, system, mottagare, överföringar och referens till gemensamt personuppgiftsansvar.
• REG08 registrerar arrangemanget för gemensamt personuppgiftsansvar och ansvarsfördelningen.
• REG07 registrerar den publika sammanfattningen för transparens.
• REG06 kan registrera mottagning, dirigering, validering, tidsfrister och svarsunderlag för rättighetsbegäranden.
• REG10 registrerar beslut om incidenter och bedömning av personuppgiftsincidenter.

Den kedjan omvandlar artikel 26 från en juridisk formulering till en ledningssystemsprocess.

Börja med omfattning, intressenter och en RACI

Zenith Blueprint börjar med omfattning och intressenter eftersom styrning av gemensamt personuppgiftsansvar brister när intressenter och krav identifieras för sent.

I fasen ISMS Foundation & Leadership, steg 2, intressentbehov och ISMS-omfattning, rekommenderar Zenith Blueprint en intressentanalys som fångar uttryckliga och underförstådda krav:

Så identifieras behov och förväntningar: För varje identifierad intressentgrupp ska det listas vad de
kräver avseende informationssäkerhet. Vissa krav är uttryckliga (lagar, avtal,
SLA:er), medan andra är underförstådda (förväntningar eller allmän god praxis). Det är till hjälp att:

✓ Granska rättsliga och regulatoriska krav som gäller i er kontext (från steg 1:s
kontextanalys). Upprätta en lista över specifika klausuler eller skyldigheter kopplade till informations-
säkerhet eller dataskydd.
✓ Granska kontrakt och avtal: många affärsavtal innehåller sekretess- eller
säkerhetsbilagor. Extrahera dessa krav.
✓ Genomföra intressentintervjuer eller workshoppar: involvera representanter från
varje grupp (t.ex. en HR-chef för medarbetarperspektivet, en försäljningschef för kunders
förväntningar) för att förstå deras frågor eller behov.
✓ Beakta branschstandarder eller uppförandekoder som intressenter förväntar sig att ni
följer.

För ett revisionsbart arrangemang för gemensamt personuppgiftsansvar enligt artikel 26 i GDPR bör intressentanalysen omfatta kunder, patienter, användare, tillsynsmyndigheter, de andra personuppgiftsansvariga parterna, personuppgiftsbiträden, underbiträden, försäkringsgivare, molnleverantörer, interna avdelningar, regulatorer och ledningsorgan.

Steg 4, roller och ansvar i ISMS, omvandlar därefter analysen till ägarskap. Zenith Blueprint lyfter värdet av en RACI-modell:

✓ Ansvarsskyldighet kontra operativt ansvar: Ett användbart verktyg här är en RACI-matris (Responsible,
Accountable, Consulted, Informed). För varje större ISMS-process eller kontroll ska det anges
vem som är Responsible (utför arbetet), vem som är Accountable (ytterst ansvarig, ofta en
chef), vem som är Consulted (lämnar synpunkter) och vem som är Informed.

För gemensamt personuppgiftsansvariga är RACI i praktiken inte valfri. Utan den antar juridikfunktionen att dataskyddsfunktionen svarar på begäran, dataskyddsfunktionen antar att supporten har mottagningskön, supporten antar att partnern ska svara och den lagstadgade tidsfristen fortsätter att löpa.

Clarysecs underlagsmodell för gemensamt personuppgiftsansvar

Ett moget arrangemang för gemensamt personuppgiftsansvar bör kunna förstås på en sida och styrkas på tio minuter. Målet är inte att tynga team med juridisk dokumentation. Målet är att göra ansvar synligt, accepterat och testbart.

Clarysecs dataskyddspolicyer förstärker varje lager.

Policy för information till registrerade och transparens, klausul 4.1.5, anger:

[Gemensamt personuppgiftsansvar] Dataskyddsansvarig/PIMS-ansvarig SKA registrera den publika sammanfattningen av ansvar vid gemensamt personuppgiftsansvar och kontaktpunkten i REG07 innan behandling under gemensamt personuppgiftsansvar lanseras eller ändras väsentligt.

Policy för hantering av PII-registrerades rättigheter, klausul 6.1.5, anger:

[Gemensamt personuppgiftsansvar] Dataskyddsansvarig/PIMS-ansvarig SKA dokumentera ansvar för rättighetshantering och kontaktvägar i REG02, REG06 eller REG08 innan behandling under gemensamt personuppgiftsansvar påbörjas.

Policy för hantering av PII-incidenter och personuppgiftsincidenter, klausul 4.2.5, tillägger:

[Gemensamt personuppgiftsansvar] Dataskyddsansvarig/PIMS-ansvarig SKA verifiera överenskommet ansvar vid personuppgiftsincident, ledande kommunikationsansvar och samordningsarrangemang innan extern anmälan eller kommunikation görs av en gemensamt personuppgiftsansvarig, och SKA registrera beslutet i REG08 och REG10.

Det är här ISO/IEC 27701:2025 och GDPR blir operativa. Organisationen säger inte bara att ansvar har fördelats. Den visar var ansvar är registrerat, vem som godkänt det, när det testades och hur det används.

Praktiskt exempel: REG08 för en plattform för fjärrövervakning

Anta att CareConnect och MetroHealth gemensamt driver en plattform för fjärrövervakning. Båda beslutar varför patientdata behandlas, vilka data som samlas in, hur övervakningslarm konfigureras, hur analys används och hur patienter interagerar med tjänsten.

Först bör REG02 registrera behandlingsaktiviteten:

• Behandlingsnamn: tjänst för fjärrövervakning av patienter
• Roll som personuppgiftsansvarig: gemensamt personuppgiftsansvarig
• Parter: CareConnect och MetroHealth
• Ändamål: patientövervakning, vårdsamordning, tjänsteförbättring, plattformsanalys
• PII-kategorier: kontaktuppgifter, kontoidentifierare, kliniska observationer, enhetshändelser, supportinteraktioner
• Kontroll av särskilda kategorier: hälsodata behandlas och kräver förstärkta skyddsåtgärder
• Rättslig grund: dokumenterad per part och ändamål
• Lagringstid: definierad utifrån kliniska, plattformsrelaterade, rättsliga och operativa krav
• System: mobilapp, övervakningsplattform, supportverktyg, analyslager, identitetsleverantör
• Mottagare: parter med gemensamt personuppgiftsansvar, driftleverantör, supportleverantörer, aviseringsleverantörer
• Överföringar: fjärråtkomst och behandling utanför EES bedömd
• REG08-referens: JC-2026-004

Därefter bör REG08 fördela ansvar på ett sätt som operativa team kan följa.

För det tredje bör REG07 registrera den publika sammanfattningen. Informationen bör förklara kärnan i det gemensamma arrangemanget på tydligt språk, identifiera de gemensamt personuppgiftsansvariga, beskriva vad var och en ansvarar för och tillhandahålla en användbar kontaktpunkt. Den ska inte tvinga patienter eller användare att tolka intern operativ komplexitet.

För det fjärde ska arbetsflödet testas före lansering. Skicka en simulerad begäran om tillgång till den publicerade kontaktpunkten. Bekräfta att supporten identifierar den som en begäran från registrerad, dirigerar den till dataskyddsfunktionen, kontrollerar REG08, begär in underlag från partnern, registrerar åtgärder i REG06 och tar fram ett svarspaket. Genomför därefter en skrivbordsövning för personuppgiftsincidenter med ett scenario som ”API-slutpunkt exponerar patientidentifierare för obehöriga användare” eller ”användare vars radering har spärrats inkluderas av misstag i en engagemangskampanj”.

Dessa tester synliggör de verkliga luckorna: oägda e-postlådor, otydliga SLA:er med partner, ej godkänd informationstext, ofullständiga poster om rättslig grund, saknade kontroller av särskilda kategorier och incidentåtgärdsplaner som inte anger ansvarig för extern kommunikation.

Mappa artikel 26 till ISO/IEC 27002:2022-kontroller genom Zenith Controls

Ett arrangemang för gemensamt personuppgiftsansvar är inte bara en juridisk artefakt. Det måste stödjas av tekniska och organisatoriska kontroller. Zenith Controls hjälper team att mappa kontrollförväntningar i ISO/IEC 27001:2022 och ISO/IEC 27002:2022 till underlag för dataskydd, leverantörer, incidenter, molntjänster och styrning.

Tre kontroller i ISO/IEC 27002:2022 är särskilt relevanta.

Kontroll 5.2, roller och ansvar för informationssäkerhet, stödjer den operativa modellen. Den kopplar till ISO/IEC 27001:2022 avsnitt 5.3, organisatoriska roller, ansvar och befogenheter. Den stödjer också incidentberedskap eftersom otydliga roller undergräver ISO/IEC 27002:2022 kontroll 5.24, planering och förberedelser för hantering av informationssäkerhetsincidenter. Vid styrning av gemensamt personuppgiftsansvar är kontroll 5.2 den plats där RACI, REG08-ägare, handläggare av rättighetsbegäranden, ansvariga för personuppgiftsincidenter och eskaleringskontakter blir revisionsunderlag.

Kontroll 5.31, rättsliga, regulatoriska, lagstadgade och avtalsmässiga krav, är där artikel 26 i GDPR blir en del av ISMS i stället för en renodlad fråga för juridikfunktionen. Den stödjer identifiering och hantering av ansvarsskyldighet enligt artikel 5 i GDPR, rättslig grund enligt artikel 6, ansvarsfördelning enligt artikel 26, säkerhet enligt artikel 32, anmälan till tillsynsmyndighet enligt artikel 33 och kommunikation till berörda enskilda enligt artikel 34. Den kopplar också till ISO/IEC 27001:2022 avsnitt 4.2, förståelse av intressenters behov och förväntningar, och avsnitt 6.1.3, riskbehandling av informationssäkerhetsrisker.

Kontroll 5.34, integritet och skydd av PII, för in skydd av PII i den säkerhetsoperativa modellen. Det är särskilt viktigt när arrangemanget använder molnbaserad analys, delade kontrollpaneler, data clean rooms, övervakningsplattformar, marknadsföringsautomatisering eller supportverktyg. Relaterade skyddsåtgärder kan omfatta ISO/IEC 27002:2022 kontroll 5.23, informationssäkerhet vid användning av molntjänster, och kontroll 8.11, datamaskering.

Det stödjande ISO-ekosystemet är också viktigt. ISO/IEC 27018 hjälper när publika molntjänster behandlar PII. ISO/IEC 29100 innehåller integritetsprinciper som transparens, samtycke, legitimt ändamål, begränsning av insamling, uppgiftsminimering, användningsbegränsning, korrekthet, säkerhetsskyddsåtgärder och ansvarsskyldighet. ISO/IEC 27001:2022 ger ledningssystemets ryggrad genom kontext, intressenter, omfattning, ledarskap, riskbedömning, riskbehandling, tillämplighetsförklaring (SoA), internrevision, ledningens genomgång och ständig förbättring.

Avtal måste motsvara den operativa modellen

Ett arrangemang för gemensamt personuppgiftsansvar kan inte bara finnas i informationen till registrerade. Det måste återspeglas i avtal, bilagor, operativa rutiner, incidentåtgärdsplaner, eskaleringsvägar och avslutsvillkor.

Clarysecs policy för efterlevnad av rättsliga och regulatoriska krav, klausul 5.3.1.2, för uttryckligen in avtalstyper i styrningen, inklusive:

Avtal som omfattar datadelning, immateriella rättigheter, ansvarsbegränsningar eller revisionsklausuler

Dataskydds- och integritetspolicy, klausul 5.1, anger grunden för organisationen:

Organisationen ska upprätthålla ett formellt ramverk för dataskyddsstyrning som är integrerat i ledningssystemet för informationssäkerhet (ISMS) för att tillämpa denna policy.

För små och medelstora företag skalas samma princip till den operativa verkligheten. Dataskydds- och integritetspolicy för små och medelstora företag, klausul 5.2.1, anger:

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

Klausul 5.2.2 tillägger:

Avtal med tredje parter som hanterar personuppgifter ska innehålla dataskyddsklausuler och ska granskas av verkställande chef eller juridisk rådgivare

Detta är proportionerlig styrning. Ett multinationellt företag kan ha separata team för juridik, dataskydd, upphandling, säkerhet, risk och regelefterlevnad. Ett mindre företag kan förlita sig på en integritetssamordnare, verkställande chef och extern juridisk rådgivare. Förväntan på underlag är densamma: behandlingsaktiviteter, ansvar, rättslig grund, information, hantering av rättigheter, incidenteskalering och avslutsskyldigheter ska vara dokumenterade och möjliga att granska.

Zenith Blueprint, steg 23, organisatoriska kontroller, stödjer disciplin i leverantörsavtal genom sekretess, ansvar för åtkomstkontroll, tekniska och organisatoriska åtgärder, tidslinjer för incidentrapportering, revisionsrätt, kontroller av underleverantörer och bestämmelser vid avtalsslut. I relationer med gemensamt personuppgiftsansvar bör dessa klausuler anpassas till datadelning och ansvarsfördelning i stället för att kopieras från en mall för personuppgiftsbiträden.

Styrning av incidenter och personuppgiftsincidenter: besluta ansvarig innan incidenten inträffar

Personuppgiftsincidenter i relationer med gemensamt personuppgiftsansvar blir kaotiska när team väntar till incidenten med att besluta vem som kommunicerar externt.

GDPR definierar en personuppgiftsincident som en säkerhetsöverträdelse som leder till oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande av eller åtkomst till personuppgifter. När det krävs ska anmälan till tillsynsmyndighet ske utan onödigt dröjsmål och, om möjligt, inom 72 timmar efter att organisationen fått kännedom om incidenten. NIS2 och DORA kan lägga till ytterligare krav på cyberincidentrapportering och kundkommunikation.

Clarysecs Incidentrespons-policy för små och medelstora företag, klausul 5.3.2, fångar tidsdisciplinen:

Tidslinjer för respons, inklusive återställning av data och anmälningsskyldigheter, ska dokumenteras och anpassas till rättsliga krav, såsom GDPR:s krav på anmälan av personuppgiftsincident inom 72 timmar.

Zenith Blueprint, steg 5, kommunikation, medvetenhet och kompetens, betonar planering av extern kommunikation, inklusive kunder, tillsynsmyndigheter, partner och allmänheten. För gemensamt personuppgiftsansvariga bör incidentmatrisen identifiera vem som gör initial klassificering av personuppgiftsincidenten, vem som kontaktar den andra personuppgiftsansvariga, vem som avgör om PII påverkas, vem som bedömer anmälningströsklar, vem som utarbetar anmälningar till myndighet, vem som kommunicerar med enskilda, vem som samordnar NIS2- eller DORA-rapportering, vem som godkänner offentliga uttalanden och vem som registrerar underlag i REG10.

Om arrangemanget omfattar en finansiell entitet enligt DORA bör incidentprocessen också stödja klassificering av större IKT-relaterade incidenter, eskalering till högsta ledningen, mellanliggande uppdateringar, slutrapportering och kundkommunikation när finansiella intressen påverkas. Om organisationen omfattas av NIS2 kan rapportering av betydande incidenter kräva stegvis anmälan och kommunikation till tjänstemottagare.

Säkrast praxis är en gemensam skrivbordsövning före lansering. Ett bra scenario tvingar team att använda REG08, REG10, incidentåtgärdsplanen, partnerkontakter, anmälningsmallar, eskaleringsträd och underlagsloggar under tidspress.

Mappning mellan efterlevnadskrav: artikel 26 står sällan ensam

Arrangemang för gemensamt personuppgiftsansvar finns ofta i bredare reglerade ekosystem. En fintech-kampanj, uppkopplad hälsoplattform, hanterad tjänsterelation, integration med molnmarknadsplats eller digitalt infrastrukturpartnerskap kan utlösa skyldigheter utöver GDPR.

NIS2 kan gälla för medelstora och stora väsentliga eller viktiga entiteter i sektorer som digital infrastruktur, molntjänster, datacenter, hanterade tjänsteleverantörer, leverantörer av hanterade säkerhetstjänster, onlinemarknadsplatser, sökmotorer och sociala nätverksplattformar. Artikel 20 i NIS2 lägger tillsyn över cybersäkerhetsriskhantering på ledningsorgan. Artikel 21 kräver tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, sårbarhetshantering, utbildning, kryptering, HR-säkerhet, åtkomstkontroll, tillgångshantering och autentisering. Artikel 23 inför stegvis rapportering av betydande incidenter.

DORA gäller från den 17 januari 2025 för många finansiella entiteter. Förordningen omfattar IKT-riskhantering, rapportering av större IKT-relaterade incidenter, testning av digital operativ motståndskraft, IKT-tredjepartsrisk, avtalsarrangemang med IKT-leverantörer och tillsyn över kritiska IKT-tredjepartstjänsteleverantörer. Artikel 5 i DORA placerar styrning av IKT-risk på ledningsorgansnivå. Artiklarna 8 till 14 omfattar identifiering av tillgångar, skydd, detektering, kontinuitet, säkerhetskopiering, återställning, erfarenhetsåterföring, utbildning och kriskommunikation. Artiklarna 17 till 20 definierar incidentlivscykel och rapportering. Artiklarna 28 till 30 gör IKT-tredjepartsrisk, avtalsvillkor, register, koncentrationsrisk, revisionsrätt och exitplanering till centrala skyldigheter.

NIST CSF 2.0 ger ett praktiskt integrationslager. Funktionen GOVERN omfattar rättsliga, regulatoriska, avtalsmässiga, dataskyddsrelaterade och civila fri- och rättighetsskyldigheter, ledningsansvar, riskaptit, policy, tillsyn och leverantörsrisk. Utfall som GV.OC-03 och GV.SC-02 ligger naturligt i linje med underlag för artikel 26 eftersom de kräver att rättsliga skyldigheter och partnerroller förstås, hanteras, kommuniceras och samordnas.

Fördelen med Clarysecs modell är återanvändning av underlag. REG08 är inte bara en GDPR-post. Den stödjer ansvarsskyldighet enligt ISO/IEC 27701:2025, styrning enligt ISO/IEC 27001:2022, tydlighet om leverantörsroller enligt NIST CSF 2.0, DORA-styrning av tredje part där finansiella tjänster berörs och ledningstillsyn enligt NIS2 där entiteten omfattas.

Vad revisorer och tillsynsmyndigheter kommer att testa

Olika granskare närmar sig styrning av gemensamt personuppgiftsansvar från olika perspektiv, men de sammanfaller i samma kärnfråga: kan organisationen visa att ansvarsskyldigheten fungerar?

Det starkaste revisionsläget är spårbarhet. Börja med det rättsliga kravet, koppla det till PIMS-policyn, peka på registerposten, visa arbetsflödet och visa därefter testunderlag eller en faktisk ärendepost.

Exempelvis kräver artikel 26 i GDPR fördelning av ansvar mellan gemensamt personuppgiftsansvariga. Policy för ledningssystem för hantering av integritetsinformation kräver REG08 innan behandlingen börjar. REG08 visar ansvarsfördelning för information, rättigheter, personuppgiftsincidenter, lagringstid, leverantörshantering och kontakter. REG07 visar den publika sammanfattningen. En simulering av en begäran från registrerad visar att arbetsflödet fungerar. Protokoll från ledningens genomgång visar undantag, beslut och förbättringar.

Det är granskningsbar styrning.

Ledningens genomgång gör integritetsrisk till ledningsansvar

Styrning av gemensamt personuppgiftsansvar ska inte döljas i en dataskyddsmapp. Den hör hemma i ledningens genomgång eftersom den påverkar regulatorisk exponering, kundförtroende, patientförtroende, incidentberedskap, leverantörsrisk, avtalsansvar och operativ resiliens.

ISO/IEC 27001:2022 kräver ledarskap och åtagande, roller, resurser, policyanpassning, riskbaserad planering, utvärdering av prestation och ständig förbättring. NIS2 lägger skyldigheter för tillsyn över cybersäkerhet på ledningsorgan. DORA lägger det yttersta ansvaret för IKT-risk på ledningsorganet för finansiella entiteter.

Clarysecs policy för styrningsroller och ansvar för små och medelstora företag, klausul 5.5, anger:

Alla betydande säkerhetsbeslut, undantag och eskaleringar ska registreras och vara spårbara.

För större organisationer kräver policy för styrningsroller och ansvar, klausul 5.2:

Ett roll- och ansvarsregister ska upprätthållas och ska omfatta:

Det registret bör omfatta dataskyddsstyrningsroller där de påverkar säkerhet, incidentrespons, leverantörsförsäkran, operativ resiliens och rapportering till verkställande ledning. Undantag kopplade till gemensamt personuppgiftsansvar bör eskaleras före lansering, inte upptäckas efter ett klagomål.

Ett praktiskt underlagspaket för ledningens genomgång bör omfatta:

• Nya och ändrade arrangemang för gemensamt personuppgiftsansvar
• Slutförandestatus för REG08
• Högriskbehandlingar och DPIA-status där tillämpligt
• Öppna frågor om rättslig grund eller transparens
• Prestanda för rättighetsbegäranden och försenade partneråtgärder
• Resultat från skrivbordsövningar för personuppgiftsincidenter och olösta luckor
• Beroenden till leverantörer, underbiträden, molntjänster och överföringar
• Undantag för lagringstid och avslut
• Revisionsiakttagelser och status för åtgärdande
• Rapporteringspåverkan för GDPR, NIS2, DORA, NIST CSF 2.0 och COBIT 2019

Clarysecs femstegsmetod för att göra artikel 26 granskningsbar

Om organisationen delar beslutsfattande över PII-behandling med en annan part ska ni inte vänta på ett klagomål, en revision, en personuppgiftsincident eller en partnerdispyt för att tydliggöra ansvar.

Använd denna femstegsmetod:

1. Använd Zenith Blueprint steg 2 för att identifiera intressenter, rättsliga krav, partnerförväntningar, dataskyddsskyldigheter och regulatorisk omfattning.
2. Använd Zenith Blueprint steg 4 för att bygga en RACI för information, rättslig grund, rättigheter, kommunikation vid personuppgiftsincidenter, lagringstid, överföringar, leverantörer, revisionsunderlag och avslut.
3. Registrera behandlingsaktiviteten i REG02 och ansvarsfördelningen för gemensamt personuppgiftsansvar i REG08 med Clarysecs PIMS-policyuppsättning.
4. Mappa arrangemanget genom Zenith Controls, särskilt ISO/IEC 27002:2022 kontroll 5.2, kontroll 5.31 och kontroll 5.34.
5. Testa arrangemanget med en simulering av en begäran från registrerad och en skrivbordsövning för personuppgiftsincidenter innan behandlingen påbörjas.

CareConnect och MetroHealth behövde inte mer informell samordning. De behövde en dokumenterad ansvarsfördelning, en publik sammanfattning, ett arbetsflöde för rättigheter, en post för samordning vid personuppgiftsincidenter, avtalsklausuler och underlag för ledningens genomgång.

Det är skillnaden mellan ”vi trodde att partnern hanterade det” och ”här finns det godkända arrangemanget, informationen, arbetsflödet, testunderlaget och beslutsunderlaget för personuppgiftsincidenten”.

Clarysec kan hjälpa er att införa PIMS-styrning enligt ISO/IEC 27701:2025, anpassa den till artikel 26 i GDPR, integrera den i ert ISMS enligt ISO/IEC 27001:2022 och ta fram revisionsklart underlag för förväntningar enligt GDPR, NIS2, DORA, NIST CSF 2.0 och COBIT 2019.

Redo att ersätta otydlighet kring gemensamt personuppgiftsansvar med revisionsklart underlag? Utforska Zenith Blueprint: en revisors färdplan i 30 steg, använd Zenith Controls: guiden för mappning mellan efterlevnadskrav eller kontakta Clarysec för en PIMS- och ISMS-bedömning som omvandlar artikel 26 till ett operativt kontrollsystem innan ert nästa partnerskap tas i produktion.