Styring af fælles dataansvarlige: revisionsvejledning til GDPR Article 26

Opkaldet kom en tirsdag morgen. For CISO’en hos CareConnect, en hurtigt voksende medico-SaaS-udbyder, var det øjeblikket, hvor grundlaget rykkede sig.

I den anden ende var compliancechefen fra MetroHealth, deres vigtigste hospitalspartner. En patient, der brugte deres fælles administrerede platform til fjernmonitorering, havde indsendt en indsigtsanmodning en måned tidligere. Ingen af organisationerne havde svaret fuldt ud. Hver organisation troede, at den anden var ansvarlig.

Derefter videresendte den juridiske afdeling endnu en besked. En juniorudvikler hos CareConnect havde ved en fejl eksponeret et ikke-kritisk API-endepunkt, som indeholdt begrænsede patientidentifikatorer. Problemet så ud til at kunne inddæmmes, og GDPR’s 72-timers frist for anmeldelse af brud var endnu ikke udløbet. Men det samme spørgsmål fastlåste begge teams.

Hvem underretter tilsynsmyndigheden? Hvem kommunikerer med patienterne? Hvem ejer privatlivsmeddelelsen? Hvem validerer anmodningen fra den registrerede? Hvem registrerer beslutningen?

Den kommercielle aftale var detaljeret om servicenedslag, fakturering, ansvarsbegrænsninger og milepæle i produktkøreplanen. Den sagde næsten intet om den operationelle virkelighed i styring af fælles dataansvarlige efter GDPR Article 26.

Det er her, mange partnerskaber fejler. Problemet er ikke, at databeskyttelses-, juridiske, sikkerheds- og indkøbsteams aldrig har hørt udtrykket “ordning for fælles dataansvarlige”. Problemet er, at ingen før behandlingens start kan dokumentere, hvem der er ansvarlig for gennemsigtighed, behandlingsgrundlag, registreredes rettigheder, eskalering ved brud, krav til videreførelse af forpligtelser til leverandører, overførsler, opbevaring, bevismateriale og kommunikation med tilsynsmyndigheder.

GDPR definerer forpligtelsen. ISO/IEC 27701:2025 giver databeskyttelsesteams en ledelsessystemstruktur. Clarysecs PIMS-politikker, Zenith Blueprint: en auditors 30-trins køreplan og Zenith Controls: vejledning til compliance på tværs omsætter Article 26 til revisionsklart operationelt bevismateriale.

Hvorfor styring af fælles dataansvarlige fejler, før nogen opdager det

Et forhold mellem fælles dataansvarlige foreligger, når to eller flere parter i fællesskab fastlægger formålene med og hjælpemidlerne til behandling af personoplysninger. Udløseren er ikke kontraktens ordlyd. Det er beslutningskompetencen.

I eksemplet med CareConnect og MetroHealth leverer CareConnect platformen, analyserne, den tekniske arkitektur, brugergrænsefladen og dataflowene. MetroHealth leverer patientrelationen, den kliniske kontekst, servicemodellen og patientdata. Begge påvirker, hvorfor personoplysninger behandles, og hvordan behandlingen fungerer. Det er noget helt andet end en leverandør, der blot hoster en database eller sender beskeder efter dokumenteret instruks.

Det samme mønster ses i kampagner om økonomisk trivsel, indlejrede forsikringspartnerskaber, online markedspladser, konsortier for svigdetektion, forbundne sundhedsplatforme, loyalitetsprogrammer, økosystemer for identitetsverifikation og analysesamarbejder. En bank, et forsikringsselskab og en SaaS-platform kan i fællesskab beslutte målsegmenter, profileringsregler, konverteringsmetrikker og markedsføringskanaler. En databehandleraftale løser ikke det problem, hvis parterne reelt er fælles dataansvarlige.

De praktiske svigt er forudsigelige:

1. Privatlivsmeddelelsen siger ikke meget mere end “vi kan dele data med partnere”.
2. Fortegnelsen over behandlingsaktiviteter identificerer parterne, men ikke fordelingen af forpligtelser.
3. Arbejdsgangen for registreredes rettigheder har ingen kanal til videresendelse, validering eller besvarelse af anmodninger.
4. Hændelsesplanen siger “underret den juridiske afdeling”, men ikke hvilken fælles dataansvarlig der leder ekstern kommunikation.
5. Kontrakten behandles som kommercielt papirarbejde, ikke som dokumentation for ansvarlighed.
6. Ophørsbestemmelser dækker ikke tilbagelevering af data, sletning, anonymisering, fjernelse af adgang eller bevarelse af bevismateriale.

GDPR Article 5 gør disse svigt revisionsfølsomme, fordi dataansvarlige ikke blot skal overholde principper som lovlighed, rimelighed, gennemsigtighed, formålsbegrænsning, dataminimering, rigtighed, opbevaringsbegrænsning, integritet, fortrolighed og ansvarlighed. De skal også kunne dokumentere overholdelsen. Article 6 tilføjer kravet om behandlingsgrundlag. Article 3 kan bringe SaaS-, fintech-, healthtech- og analyseudbydere uden for EU ind i anvendelsesområdet, når de tilbyder tjenester til personer i EU eller overvåger deres adfærd.

Læringen for CISO’er og complianceansvarlige er direkte: styring af fælles dataansvarlige er ikke “bare juridisk afdeling”. Det er et tværfunktionelt kontrolsystem, der omfatter databeskyttelse, sikkerhed, indkøb, produkt, udvikling, support, hændelseshåndtering, marketing og ledelsesmæssigt tilsyn.

ISO/IEC 27701:2025 PIMS-princippet: beslut før behandlingen starter

Et ISO/IEC 27701:2025-ledelsessystem for databeskyttelse fungerer kun, hvis databeskyttelsesroller fastlægges, før behandlingen begynder. Det er den operationelle disciplin, der forhindrer Article 26 i at blive en rekonstruktion efter en hændelse.

Clarysecs politik for ledelsessystem for databeskyttelse, klausul 4.2.2, fastslår:

[Fælles dataansvarlig] Leverandøransvarlig / indkøbsansvarlig SKAL dokumentere ansvarsfordelingen mellem fælles dataansvarlige i REG08, før fælles behandling begynder.

Formuleringen “før fælles behandling begynder” er kontrolpunktet. Det betyder før platformintegrationen sættes i drift, før det delte dashboard aktiveres, før CRM-synkronisering starter, før kampagnemålgrupper aktiveres, og før anmodninger fra registrerede begynder at komme ind.

Den understøttende forpligtelse vedrørende fortegnelsen fremgår af politik for PII-behandlingsfortegnelse og behandlingsgrundlag, klausul 4.3.5:

[Fælles dataansvarlig] Leverandøransvarlig / indkøbsansvarlig SKAL registrere behandlingsformålet for fælles dataansvarlige og reference til ansvarsfordelingen i REG02 og REG08, før behandling som fælles dataansvarlige begynder.

Tilsammen skaber disse klausuler den beviskæde, som auditorer forventer:

• REG02 registrerer behandlingsaktiviteten, formål, datakategorier, behandlingsgrundlag, opbevaring, systemer, modtagere, overførsler og reference til fælles dataansvarlige.
• REG08 registrerer ordningen for fælles dataansvarlige og ansvarsfordelingen.
• REG07 registrerer det offentligt tilgængelige resumé om gennemsigtighed.
• REG06 kan registrere modtagelse, routing, validering, frister og svardokumentation for rettighedsanmodninger.
• REG10 registrerer beslutninger om vurdering af hændelser og brud.

Denne kæde omsætter Article 26 fra en juridisk erklæring til en ledelsessystemproces.

Start med omfang, interessenter og en RACI

Zenith Blueprint starter med omfang og interessenter, fordi styring af fælles dataansvarlige fejler, når interessenter og krav identificeres for sent.

I fasen ISMS Foundation & Leadership, trin 2, interessentbehov og ISMS-omfang, anbefaler Zenith Blueprint en interessentanalyse, der indfanger eksplicitte og implicitte krav:

Sådan identificeres behov og forventninger: For hver identificeret interessentgruppe skal det angives, hvad de
kræver med hensyn til informationssikkerhed. Nogle krav er eksplicitte (love, kontrakter,
SLA’er), mens andre er implicitte (forventninger eller almindelig god praksis). Det hjælper at:

✓ Gennemgå juridiske og regulatoriske krav, der gælder for jeres kontekst (fra trin 1’s
kontekstanalyse). Udarbejd en liste over specifikke klausuler eller forpligtelser relateret til informations-
sikkerhed eller databeskyttelse.
✓ Gennemgå kontrakter og aftaler: Mange forretningskontrakter har tillæg om fortrolighed eller
sikkerhed. Udtræk disse krav.
✓ Gennemføre interessentinterviews eller workshops: Involver repræsentanter fra
hver gruppe (f.eks. en HR-chef for medarbejderperspektivet, en salgschef for kunders
forventninger) for at forstå deres bekymringer eller behov.
✓ Overvej branchestandarder eller adfærdskodekser, som interessenter forventer, at I
følger.

For en reviderbar ordning for fælles dataansvarlige efter GDPR Article 26 bør interessentanalysen omfatte kunder, patienter, brugere, tilsynsmyndigheder, de øvrige dataansvarlige parter, databehandlere, underdatabehandlere, forsikringsselskaber, cloududbydere, interne afdelinger, regulatorer og ledelsesorganer.

Trin 4, roller og ansvar i ISMS, omsætter derefter analysen til ejerskab. Zenith Blueprint fremhæver værdien af en RACI-model:

✓ Accountability vs. Responsibility: Et nyttigt værktøj her er en RACI-matrix (Responsible,
Accountable, Consulted, Informed). For hver væsentlig ISMS-proces eller kontrol identificeres,
hvem der er Responsible (udfører arbejdet), hvem der er Accountable (ultimativt ansvarlig, ofte en
leder), hvem der er Consulted (leverer input), og hvem der er Informed.

For fælles dataansvarlige er RACI’en i praksis ikke valgfri. Uden den antager den juridiske afdeling, at databeskyttelsesfunktionen besvarer anmodningen, databeskyttelsesfunktionen antager, at support ejer intake-køen, support antager, at partneren svarer, og den lovbestemte frist fortsætter med at løbe.

Clarysecs bevismodel for fælles dataansvarlige

En moden ordning for fælles dataansvarlige bør kunne forstås på én side og dokumenteres på ti minutter. Målet er ikke at drukne teams i juridisk papirarbejde. Målet er at gøre ansvar synligt, accepteret og testbart.

Clarysecs databeskyttelsespolitikker styrker hvert lag.

Politik for privatlivsmeddelelser og gennemsigtighed, klausul 4.1.5, fastslår:

[Fælles dataansvarlig] Databeskyttelsesansvarlig / PIMS-ansvarlig SKAL registrere det offentligt tilgængelige resumé af ansvarsfordelingen mellem fælles dataansvarlige og kontaktpunktet i REG07, før behandling som fælles dataansvarlige lanceres eller ændres væsentligt.

Politik for håndtering af registreredes rettigheder, klausul 6.1.5, fastslår:

[Fælles dataansvarlig] Databeskyttelsesansvarlig / PIMS-ansvarlig SKAL dokumentere ansvar for håndtering af rettigheder og kontaktveje i REG02, REG06 eller REG08, før behandling som fælles dataansvarlige begynder.

Politik for PII-hændelser og brud, klausul 4.2.5, tilføjer:

[Fælles dataansvarlig] Databeskyttelsesansvarlig / PIMS-ansvarlig SKAL verificere det aftalte ansvar ved brud, det primære kommunikationsansvar og koordineringsordningen før enhver ekstern underretning eller kommunikation fra en fælles dataansvarlig, og SKAL registrere beslutningen i REG08 og REG10.

Her bliver ISO/IEC 27701:2025 og GDPR operationelle. Organisationen siger ikke blot, at ansvar er fordelt. Den viser, hvor ansvaret er registreret, hvem der har godkendt det, hvornår det er testet, og hvordan det anvendes.

Praktisk eksempel: REG08 for en platform til fjernmonitorering

Antag, at CareConnect og MetroHealth i fællesskab driver en platform til fjernmonitorering. Begge beslutter, hvorfor patientdata behandles, hvilke data der indsamles, hvordan overvågningsalarmer konfigureres, hvordan analyser anvendes, og hvordan patienter interagerer med tjenesten.

Først bør REG02 registrere behandlingsaktiviteten:

• Behandlingens navn: Tjeneste til fjernmonitorering af patienter
• Rolle som dataansvarlig: Fælles dataansvarlig
• Parter: CareConnect og MetroHealth
• Formål: patientmonitorering, koordinering af behandling, forbedring af tjenesten, platformanalyse
• Kategorier af personoplysninger: kontaktdata, kontoidentifikatorer, kliniske observationer, enhedshændelser, supportinteraktioner
• Kontrol af særlige kategorier: helbredsoplysninger behandles og kræver skærpede sikkerhedsforanstaltninger
• Behandlingsgrundlag: dokumenteret pr. part og formål
• Opbevaring: defineret ud fra kliniske, platformsmæssige, juridiske og driftsmæssige krav
• Systemer: mobilapp, monitoreringsplatform, supportværktøj, analysedatavarehus, identitetsudbyder
• Modtagere: fælles dataansvarlige parter, hostingudbyder, supportleverandører, udbydere af underretninger
• Overførsler: fjernadgang og behandling uden for EØS vurderet
• REG08-reference: JC-2026-004

Derefter bør REG08 fordele ansvar på en måde, som driftsfunktioner kan følge.

For det tredje bør REG07 registrere det offentligt tilgængelige resumé. Meddelelsen bør forklare det væsentlige indhold af den fælles ordning i klart sprog, identificere de fælles dataansvarlige, beskrive hvad hver part er ansvarlig for og angive et anvendeligt kontaktpunkt. Den bør ikke tvinge patienter eller brugere til at afkode intern operationel kompleksitet.

For det fjerde skal arbejdsgangen testes før lancering. Send en simuleret indsigtsanmodning til det offentliggjorte kontaktpunkt. Bekræft, at support identificerer den som en rettighedsanmodning fra en registreret, router den til databeskyttelsesfunktionen, kontrollerer REG08, anmoder om partnerinput, registrerer handlinger i REG06 og producerer en svarpakke. Gennemfør derefter en tabletop-øvelse ved brud med et scenarie som “API-endepunkt eksponerer patientidentifikatorer for uautoriserede brugere” eller “brugere med sletningsundertrykkelse inkluderes ved en fejl i en engagementskampagne”.

Disse tests afdækker de reelle huller: postkasser uden ejer, uklare partner-SLA’er, ikke-godkendt tekst til meddelelser, ufuldstændige registreringer af behandlingsgrundlag, manglende kontroller af særlige kategorier og hændelsesplaybooks, der ikke navngiver den ansvarlige for ekstern kommunikation.

Kortlæg Article 26 til ISO/IEC 27002:2022-kontroller gennem Zenith Controls

En ordning for fælles dataansvarlige er ikke kun et juridisk artefakt. Den skal understøttes af tekniske og organisatoriske kontroller. Zenith Controls hjælper teams med at kortlægge kontrolforventninger i ISO/IEC 27001:2022 og ISO/IEC 27002:2022 til bevismateriale for databeskyttelse, leverandører, hændelser, cloud og governance.

Tre ISO/IEC 27002:2022-kontroller er særligt relevante.

Control 5.2, Information Security Roles and Responsibilities, understøtter den operationelle model. Den kobler til ISO/IEC 27001:2022 Clause 5.3, Organizational roles, responsibilities and authorities. Den understøtter også hændelsesberedskab, fordi uklare roller underminerer ISO/IEC 27002:2022 Control 5.24, Information Security Incident Management Planning and Preparation. I styring af fælles dataansvarlige er Control 5.2 stedet, hvor RACI, REG08-ejere, DSR-håndterere, ansvarlige for brud og eskalationskontakter bliver til revisionsbevismateriale.

Control 5.31, Legal, Statutory, Regulatory and Contractual Requirements, er stedet, hvor GDPR Article 26 bliver en del af ISMS i stedet for et rent juridisk anliggende. Den understøtter identifikation og styring af GDPR Article 5-ansvarlighed, Article 6-behandlingsgrundlag, ansvarsfordeling efter Article 26, Article 32-sikkerhed, Article 33-underretning af tilsynsmyndighed og Article 34-kommunikation til berørte personer. Den kobler også til ISO/IEC 27001:2022 Clause 4.2, forståelse af interessenters behov og forventninger, og Clause 6.1.3, risikobehandling for informationssikkerhed.

Control 5.34, Privacy and Protection of PII, bringer beskyttelse af personoplysninger ind i den sikkerhedsmæssige driftsmodel. Den er særlig vigtig, hvor ordningen anvender cloudanalyse, delte dashboards, data clean rooms, monitoreringsplatforme, marketingautomatisering eller supportværktøjer. Relaterede sikkerhedsforanstaltninger kan omfatte ISO/IEC 27002:2022 Control 5.23, Information Security for Use of Cloud Services, og Control 8.11, Data Masking.

Det understøttende ISO-økosystem er også vigtigt. ISO/IEC 27018 hjælper, hvor offentlige cloudtjenester behandler personoplysninger. ISO/IEC 29100 giver privatlivsprincipper såsom gennemsigtighed, samtykke, legitimt formål, indsamlingsbegrænsning, dataminimering, anvendelsesbegrænsning, rigtighed, sikkerhedsforanstaltninger og ansvarlighed. ISO/IEC 27001:2022 giver ledelsessystemets rygrad gennem kontekst, interessenter, omfang, lederskab, risikovurdering, risikobehandling, anvendelighedserklæring, intern revision, ledelsens gennemgang og løbende forbedring.

Kontrakter skal matche den operationelle model

En ordning for fælles dataansvarlige kan ikke kun eksistere i en privatlivsmeddelelse. Den skal afspejles i kontrakter, bilag, driftsprocedurer, hændelsesplaybooks, eskalationsveje og ophørsbestemmelser.

Clarysecs politik for juridisk og regulatorisk compliance, klausul 5.3.1.2, bringer eksplicit kontrakttyper ind i styringen, herunder:

Kontrakter, der omfatter datadeling, immaterielle rettigheder, ansvarsbegrænsninger eller revisionsklausuler

Databeskyttelses- og privatlivspolitik, klausul 5.1, fastlægger fundamentet for virksomheden:

Organisationen skal vedligeholde en formel ramme for styring af databeskyttelse, integreret i ledelsessystemet for informationssikkerhed (ISMS), for at håndhæve denne politik.

For SMV’er skaleres samme princip til den operationelle virkelighed. Databeskyttelses- og privatlivspolitik for SMV’er, klausul 5.2.1, fastslår:

Koordinatoren for databeskyttelse skal vedligeholde et register over alle behandlingsaktiviteter vedrørende personoplysninger, herunder datakategorier, formål, behandlingsgrundlag og opbevaringsperioder

Klausul 5.2.2 tilføjer:

Kontrakter med tredjeparter, der håndterer personoplysninger, skal indeholde databeskyttelsesklausuler og skal gennemgås af direktøren eller den juridiske rådgiver

Dette er proportional styring. En multinational organisation kan have særskilte juridiske, databeskyttelses-, indkøbs-, sikkerheds-, risiko- og complianceteams. En SMV kan være afhængig af en koordinator for databeskyttelse, en direktør og en ekstern juridisk rådgiver. Forventningen til bevismateriale er den samme: behandlingsaktiviteter, ansvar, behandlingsgrundlag, meddelelser, håndtering af rettigheder, eskalering ved hændelser og ophørsforpligtelser skal være dokumenterede og gennemgåelige.

Zenith Blueprint, trin 23, organisatoriske kontroller, understøtter disciplin i leverandøraftaler gennem fortrolighed, ansvar for adgangsstyring, tekniske og organisatoriske foranstaltninger, frister for hændelsesrapportering, revisionsrettigheder, kontroller for underleverandører og bestemmelser ved kontraktophør. I forhold mellem fælles dataansvarlige bør disse klausuler tilpasses datadeling og ansvarsfordeling i stedet for at blive kopieret fra en databehandlerskabelon.

Styring af hændelser og brud: beslut den ansvarlige før bruddet

Brud hos fælles dataansvarlige bliver kaotiske, når teams venter til hændelsen med at beslutte, hvem der kommunikerer eksternt.

GDPR definerer et brud på persondatasikkerheden som et brud på sikkerheden, der fører til hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger. Hvor det kræves, skal underretning af tilsynsmyndigheden ske uden unødig forsinkelse og, hvor det er muligt, inden 72 timer efter, at organisationen er blevet bekendt med bruddet. NIS2 og DORA kan tilføje yderligere forventninger om rapportering af cyberhændelser og kundekommunikation.

Clarysecs politik for hændelseshåndtering for SMV’er, klausul 5.3.2, indfanger disciplinen omkring timing:

Responstidslinjer, herunder datagendannelse og underretningsforpligtelser, skal dokumenteres og tilpasses retlige krav, såsom GDPR’s krav om anmeldelse af brud på persondatasikkerheden inden 72 timer.

Zenith Blueprint, trin 5, kommunikation, bevidsthed og kompetence, fremhæver planlægning af ekstern kommunikation, herunder kunder, tilsynsmyndigheder, partnere og offentligheden. For fælles dataansvarlige bør hændelsesmatricen identificere, hvem der udfører den indledende klassificering af bruddet, hvem der kontakter den anden dataansvarlige, hvem der afgør, om personoplysninger er berørt, hvem der vurderer underretningstærskler, hvem der udarbejder underretninger til myndigheder, hvem der kommunikerer med personer, hvem der koordinerer NIS2- eller DORA-rapportering, hvem der godkender offentlige udtalelser, og hvem der registrerer bevismateriale i REG10.

Hvis ordningen involverer en finansiel enhed omfattet af DORA, bør hændelsesprocessen også understøtte klassificering af større IKT-relaterede hændelser, eskalering til øverste ledelse, mellemliggende opdateringer, slutrapportering og kundekommunikation, hvor finansielle interesser er berørt. Hvis organisationen er omfattet af NIS2, kan rapportering af væsentlige hændelser kræve faseopdelt underretning og kommunikation til tjenestemodtagere.

Den sikreste praksis er en fælles tabletop-øvelse før lancering. Et godt scenarie tvinger teams til at bruge REG08, REG10, hændelsesplaybooken, partnerkontakter, underretningsskabeloner, eskalationstræer og logfiler for bevismateriale under tidspres.

Compliance på tværs: Article 26 står sjældent alene

Ordninger for fælles dataansvarlige indgår ofte i bredere regulerede økosystemer. En fintech-kampagne, forbundet sundhedsplatform, managed service-forhold, cloud marketplace-integration eller partnerskab om digital infrastruktur kan udløse forpligtelser ud over GDPR.

NIS2 kan gælde for mellemstore og store væsentlige eller vigtige enheder i sektorer som digital infrastruktur, cloud computing, datacentre, managed service providers, managed security service providers, online markedspladser, søgemaskiner og sociale netværksplatforme. NIS2 Article 20 placerer tilsyn med cybersikkerhedsrisikostyring hos ledelsesorganer. Article 21 kræver tekniske, operationelle og organisatoriske foranstaltninger, herunder risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, sårbarhedshåndtering, træning, kryptering, HR-sikkerhed, adgangsstyring, styring af aktiver og autentifikation. Article 23 indfører faseopdelt rapportering for væsentlige hændelser.

DORA finder anvendelse fra 17. januar 2025 for mange finansielle enheder. Den dækker styring af IKT-risiko, rapportering af større IKT-relaterede hændelser, test af digital operationel robusthed, IKT-tredjepartsrisiko, kontraktlige ordninger med IKT-udbydere og tilsyn med kritiske IKT-tredjepartsudbydere. DORA Article 5 placerer styring af IKT-risiko på ledelsesorganniveau. Articles 8 to 14 dækker aktividentifikation, beskyttelse, detektion, kontinuitet, backup, genopretning, læringspunkter, træning og krisekommunikation. Articles 17 to 20 definerer hændelseslivscyklus og rapportering. Articles 28 to 30 gør IKT-tredjepartsrisiko, kontraktvilkår, registre, koncentrationsrisiko, revisionsrettigheder og exitplanlægning til centrale forpligtelser.

NIST CSF 2.0 giver et praktisk integrationslag. GOVERN-funktionen omfatter juridiske, regulatoriske, kontraktlige, databeskyttelses- og borgerrettighedsforpligtelser, ledelsesansvarlighed, risikovillighed, politik, tilsyn og leverandørrisiko. Outcomes som GV.OC-03 og GV.SC-02 passer naturligt med Article 26-bevismateriale, fordi de kræver, at juridiske forpligtelser og partnerroller forstås, styres, kommunikeres og koordineres.

Fordelen ved Clarysecs model er genbrug af bevismateriale. REG08 er ikke kun en GDPR-registrering. Den understøtter ansvarlighed efter ISO/IEC 27701:2025, styring efter ISO/IEC 27001:2022, rolleklarhed for leverandører i NIST CSF 2.0, tredjepartsstyring efter DORA, hvor finansielle tjenester er involveret, og ledelsesorganets tilsyn efter NIS2, hvor enheden er omfattet.

Hvad auditorer og tilsynsmyndigheder vil teste

Forskellige reviewere vil tilgå styring af fælles dataansvarlige fra forskellige vinkler, men de vil samles om det samme kernespørgsmål: kan organisationen dokumentere, at ansvarlighed fungerer?

Den stærkeste revisionsposition er sporbarhed. Start med det juridiske krav, forbind det med PIMS-politikken, peg på registerposten, vis arbejdsgangen, og vis derefter testbevismateriale eller en reel sagsregistrering.

For eksempel kræver GDPR Article 26 fordeling af ansvar mellem fælles dataansvarlige. Politik for ledelsessystem for databeskyttelse kræver REG08, før behandlingen begynder. REG08 viser ansvarsfordelingen for meddelelser, rettigheder, brud, opbevaring, leverandørstyring og kontakter. REG07 viser det offentligt tilgængelige resumé. En simulering af en rettighedsanmodning dokumenterer, at arbejdsgangen fungerer. Referater fra ledelsens gennemgang viser undtagelser, beslutninger og forbedringer.

Det er reviderbar styring.

Ledelsens gennemgang omsætter databeskyttelsesrisiko til ledelsesansvar

Styring af fælles dataansvarlige bør ikke gemmes i en databeskyttelsesmappe. Den hører hjemme i ledelsens gennemgang, fordi den påvirker regulatorisk eksponering, kundetillid, patienttillid, hændelsesberedskab, leverandørrisiko, kontraktligt ansvar og operationel robusthed.

ISO/IEC 27001:2022 kræver ledelsesforpligtelse, roller, ressourcer, tilpasning af politikker, risikobaseret planlægning, performanceevaluering og løbende forbedring. NIS2 placerer tilsynsforpligtelser vedrørende cybersikkerhed hos ledelsesorganer. DORA placerer det endelige ansvar for IKT-risiko hos ledelsesorganet for finansielle enheder.

Clarysecs politik for styringsroller og ansvarsområder for SMV’er, klausul 5.5, fastslår:

Alle væsentlige sikkerhedsbeslutninger, undtagelser og eskaleringer skal registreres og være sporbare.

For enterprise-organisationer kræver politik for styringsroller og ansvarsområder, klausul 5.2:

Et register over roller og ansvarsområder skal vedligeholdes og skal omfatte:

Dette register bør omfatte roller for styring af databeskyttelse, hvor de påvirker sikkerhed, hændelseshåndtering, leverandørassurance, operationel robusthed og ledelsesrapportering. Undtagelser vedrørende fælles dataansvarlige bør eskaleres før lancering, ikke opdages efter en klage.

En praktisk pakke til ledelsens gennemgang bør omfatte:

• Nye og ændrede ordninger for fælles dataansvarlige
• Status for fuldførelse af REG08
• Højrisiko-behandlingsaktiviteter og DPIA-status, hvor relevant
• Åbne forhold vedrørende behandlingsgrundlag eller gennemsigtighed
• DSR-performance og forsinkede partnerhandlinger
• Resultater fra tabletop-øvelser ved brud og uafklarede huller
• Afhængigheder vedrørende leverandører, underdatabehandlere, cloud og overførsler
• Undtagelser vedrørende opbevaring og ophør
• Revisionskonstateringer og afhjælpningsstatus
• Rapporteringspåvirkning for GDPR, NIS2, DORA, NIST CSF 2.0 og COBIT 2019

En femtrins Clarysec-tilgang til at gøre Article 26 reviderbar

Hvis din organisation deler beslutningskompetence over behandling af personoplysninger med en anden part, skal I ikke vente på en klage, revision, et brud eller en partnertvist med at afklare ansvaret.

Brug denne femtrins tilgang:

1. Brug Zenith Blueprint trin 2 til at identificere interessenter, juridiske krav, partnerforventninger, databeskyttelsesforpligtelser og regulatorisk anvendelsesområde.
2. Brug Zenith Blueprint trin 4 til at opbygge en RACI for meddelelser, behandlingsgrundlag, rettigheder, kommunikation ved brud, opbevaring, overførsler, leverandører, revisionsbevismateriale og ophør.
3. Registrér behandlingsaktiviteten i REG02 og ansvarsfordelingen mellem fælles dataansvarlige i REG08 ved hjælp af Clarysecs PIMS-politiksæt.
4. Kortlæg ordningen gennem Zenith Controls, især ISO/IEC 27002:2022 Control 5.2, Control 5.31 og Control 5.34.
5. Test ordningen med en simulering af en rettighedsanmodning og en tabletop-øvelse ved brud, før behandlingen begynder.

CareConnect og MetroHealth havde ikke brug for mere uformel afstemning. De havde brug for en dokumenteret ansvarsfordeling, et offentligt tilgængeligt resumé, en arbejdsgang for rettigheder, en registrering af koordinering ved brud, kontraktklausuler og bevismateriale fra ledelsens gennemgang.

Det er forskellen på “vi troede, at partneren håndterede det” og “her er den godkendte ordning, meddelelse, arbejdsgang, testbevismateriale og beslutningsregistrering ved brud”.

Clarysec kan hjælpe jer med at implementere ISO/IEC 27701:2025 PIMS-styring, tilpasse den til GDPR Article 26, integrere den i jeres ISO/IEC 27001:2022 ISMS og producere revisionsklart bevismateriale på tværs af forventninger i GDPR, NIS2, DORA, NIST CSF 2.0 og COBIT 2019.

Klar til at erstatte uklarhed om fælles dataansvarlige med revisionsklart bevismateriale? Udforsk Zenith Blueprint: en auditors 30-trins køreplan, brug Zenith Controls: vejledning til compliance på tværs, eller kontakt Clarysec for en PIMS- og ISMS-vurdering, der omsætter Article 26 til et operationelt kontrolsystem, før jeres næste partnerskab sættes i drift.