Anvendelighed af ISO 27701-kontroller under GDPR-roller

Klokken er 08:40 en tirsdag, og Maria, CISO i en hurtigt voksende health-tech SaaS-virksomhed, sidder med fire kunde-e-mails, der næsten ligner hinanden, men som betyder vidt forskellige ting.

Én enterprise-kunde beder om bevismateriale for, at virksomheden kan fungere som GDPR-databehandler efter Article 28. En anden spørger, om platformen også er dataansvarlig for telemetri og produktanalyse. En tredje beder om den aktuelle liste over underdatabehandlere og dokumentation for, at databehandleraftalens klausuler er videreført. En fjerde, en fintech-kunde, der forbereder sig på DORA-leverandørgennemgange, spørger, om de samme databeskyttelseskontroller er kortlagt til operationel robusthed, hændelsesrapportering og IKT-tredjepartsrisiko.

Marias virksomhed er ikke uforsigtig. Den har et ISMS, der er tilpasset ISO/IEC 27001:2022, databeskyttelsespolitikker, en fortegnelse over behandlingsaktiviteter, MFA, kryptering, adgangsrettighedsgennemgange og træning i databeskyttelse gennem design. Men anmodningen afdækker det sværere spørgsmål, som revisorer og kunder faktisk tester:

Kan virksomheden dokumentere, at de rette ISO 27701 PIMS-kontroller gælder for den rette GDPR-rolle, for den rette behandlingsaktivitet, med den rette ejer, det rette bevismateriale og den rette begrundelse?

Det er her, mange databeskyttelsesprogrammer fejler. De behandler ISO 27701 som en tjekliste, selv om certificeringsorganer, kunderevisorer og databeskyttelsesrådgivere forventer en begrundet beslutning om kontrollernes anvendelighed. Svaret er ikke: “vi har databeskyttelseskontroller”. Svaret er: “for denne behandlingsaktivitet er vi dataansvarlig, databehandler, fælles dataansvarlig eller underdatabehandler, og her er begrundelsen for, at disse kontroller gælder eller ikke gælder.”

Hvorfor anvendeligheden af ISO 27701-kontroller er det manglende PIMS-lag

GDPR-roller er baseret på beslutningskompetence. En dataansvarlig fastlægger formål og hjælpemidler for behandlingen. En databehandler handler på vegne af en dataansvarlig. Fælles dataansvarlige fastlægger i fællesskab formål og hjælpemidler. En underdatabehandler engageres af en databehandler til at behandle personoplysninger længere nede i kæden.

I reelle SaaS-miljøer er rollerne sjældent entydige på organisationsniveau. Marias organisation er databehandler, når den hoster kunders wellness-data, dataansvarlig for medarbejderløn og marketingkontakter, muligvis dataansvarlig for produkttelemetri afhængigt af formål og kontraktvilkår, og fælles dataansvarlig i en co-branded kampagne. Hvis en større udbyder af administrerede tjenester videresælger hendes platform, kan virksomheden også blive underdatabehandler i den kæde.

Anvendeligheden af ISO 27701-kontroller er den disciplin, der forhindrer rollerne i at blive reduceret til upræcise erklæringer. Den stiller følgende spørgsmål:

• Hvilken behandlingsaktivitet er omfattet?
• Hvilken GDPR-rolle har organisationen for aktiviteten?
• Hvilke PIMS-kontroller gælder på grund af rollen?
• Hvilke kontroller er udelukket, og hvorfor?
• Hvilket bevismateriale dokumenterer implementeringen?
• Hvilket juridisk, kontraktligt, risikobaseret eller omfangsrelateret krav lå til grund for beslutningen?

Clarysecs Privacy Information Management System Policy gør rolleklassificering til udgangspunktet:

“[Begge] Procesejeren / forretningsejeren SKAL klassificere organisationens PIMS-rolle for hver PII-behandlingsaktivitet i REG02, før behandlingsaktiviteten påbegyndes.”

Fra afsnittet “Fastlæggelse af PIMS-rolle”, politikklausul 4.2.1.

Den samme politik forbinder rollebeslutningen med kontrollernes anvendelighed:

“[Begge] Den databeskyttelsesansvarlige / PIMS-ansvarlige SKAL vedligeholde REG03 med inkluderede kontroller, udelukkede kontroller, implementeringsstatus og begrundelse årligt og inden for 30 dage efter hver ændring i risikobehandling vedrørende databeskyttelse.”

Fra afsnittet “Databeskyttelsespolitik, mål og kontrollernes anvendelighed”, politikklausul 4.3.3.

REG02 besvarer, hvilken behandling der findes, og hvilken rolle der gælder. REG03 besvarer, hvilke kontroller der gælder, hvad der er udelukket, hvilket bevismateriale der findes, og hvorfor beslutningen er forsvarlig.

Byg PIMS på ISO/IEC 27001:2022 SoA-logik

Et rollebaseret PIMS fungerer bedst, når det bygges oven på et modent ISMS. ISO/IEC 27001:2022 kræver allerede fastlæggelse af omfang, analyse af interessenter, risikovurdering, risikobehandling, kontroludvælgelse og en anvendelighedserklæring. ISO 27701 udvider denne ledelsessystemlogik til databeskyttelse.

Clarysecs Information Security Policy fastslår:

“ISMS’et skal omfatte definerede omfangsafgrænsninger, en risikovurderingsmetodik, målbare målsætninger og dokumenterede kontroller, der er begrundet i anvendelighedserklæringen (SoA).”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.2.

Risk Management Policy understøtter den samme disciplin for bevismateriale:

“En anvendelighedserklæring (SoA) skal afspejle alle behandlingsbeslutninger og skal opdateres, når kontroldækningen ændres.”

Fra afsnittet “Governancekrav”, politikklausul 5.4.

For databeskyttelse bliver REG03 til PIMS-registeret over kontrollernes anvendelighed, som afspejler SoA-disciplinen. Det erstatter ikke ISO/IEC 27001:2022 SoA. Det beriger den ved at tilføje GDPR-rollebaserede databeskyttelsesbeslutninger for dataansvarlige, databehandlere, fælles dataansvarlige og underdatabehandlere.

PII Processing Inventory and Lawful Basis Policy gør denne kobling eksplicit:

“[Begge] Den databeskyttelsesansvarlige / PIMS-ansvarlige SKAL knytte relevante REG02-behandlingsaktiviteter til REG03-registreringer af kontrollernes anvendelighed før gennemgang af revisionsberedskab til certificering.”

Fra afsnittet “Drift af fortegnelsen over behandlingsaktiviteter”, politikklausul 7.1.5.

En revisor skal kunne udvælge én behandlingsaktivitet i REG02, identificere GDPR-rollen, spore de anvendelige kontroller i REG03, gennemgå de relevante ISO/IEC 27001:2022-kontroller i SoA og inspicere bevismateriale såsom en databehandleraftale, registrering af behandlingsgrundlag, adgangsrettighedsgennemgang, godkendelse af underdatabehandler, hændelsesprocedure eller sletningslog.

Den rollebaserede model for kontrollernes anvendelighed

Den hurtigste måde at gøre ISO 27701 anvendelig på er at beslutte anvendelighed på behandlingsaktivitetsniveau, ikke på organisationsniveau.

En SaaS-udbyder bør undgå at sige: “vi er databehandler”. Den bør sige: “for brugerregistreringer uploadet af kunder til produktionsplatformen er vi databehandler. For løn er vi dataansvarlig. For produktanalyse afhænger vores rolle af, om analysen kun bruges til at levere de aftalte tjenester eller til vores egne selvstændige formål. For ticketing-leverandøren, der understøtter kundedata, er leverandøren underdatabehandler.”

Denne rollebaserede tilgang er i overensstemmelse med GDPR’s ansvarlighedsprincip. Dataansvarlige skal dokumentere efterlevelse af principper som lovlighed, rimelighed, gennemsigtighed, formålsbegrænsning, dataminimering, rigtighed, opbevaringsbegrænsning, integritet, fortrolighed og ansvarlighed. Databehandlere må kun behandle på grundlag af dokumenterede instrukser, skal implementere passende sikkerhed, bistå dataansvarlige, styre underdatabehandlere og understøtte returnering eller sletning.

Den farlige genvej er at antage, at alle databeskyttelseskontroller gælder overalt. En databehandler fastlægger normalt ikke behandlingsgrundlaget for kundens slutbrugerdata, men skal kunne dokumentere, at behandlingen kun sker efter kundens instrukser. En dataansvarlig behøver måske ikke kundegodkendelse af underdatabehandlere for intern HR-behandling, men skal udføre databehandler-due diligence for lønudbyderen.

Klassificér før kontraktgodkendelse eller behandlingsstart

Den mest almindelige PIMS-beredskabskonstatering er sen rolleklassificering. Kontrakten er underskrevet, platformen er i drift, leverandører er integreret, og ingen har besluttet, om organisationen er dataansvarlig, databehandler, fælles dataansvarlig eller underdatabehandler for hvert dataflow.

Forsinkelsen skaber problemer længere nede i processen. Den forkerte databehandleraftale bruges. Underdatabehandlere oplyses ikke. DPIA’er overses. Opbevaring er uklar. Kundesupport ved ikke, hvilken underretningsfrist ved brud der gælder. Indkøb behandler en leverandør med databeskyttelsespåvirkning som “bare et værktøj”.

Processor, Subprocessor and Third-Party Privacy Management Policy adresserer tidspunktet direkte:

“[Begge] Den databeskyttelsesansvarlige / PIMS-ansvarlige SKAL klassificere hvert tredjepartsforhold vedrørende databeskyttelse som dataansvarlig, fælles dataansvarlig, databehandler, underdatabehandler eller andet tredjepartsforhold i REG08 før kontraktgodkendelse eller før PII-behandling påbegyndes, alt efter hvad der indtræffer først.”

Fra afsnittet “Identifikation og klassificering af relationer”, politikklausul 4.1.3.

REG08-klassificering af leverandør- og tredjepartsrelationer føder ind i REG03. Hvis en leverandør er databehandler, omfatter de anvendelige kontroller databehandleraftalevilkår, fortrolighed, sikkerhedsforanstaltninger, revisionsrettigheder, bistand ved rettighedsanmodninger, bistand ved brud, returnering eller sletning og kontroller for underdatabehandlere. Hvis en leverandør er selvstændig dataansvarlig, flyttes fokus til juridisk grundlag, styring af videregivelse, overførsler, gennemsigtighed og ansvarlighed.

For mindre organisationer kræver Third-Party and Supplier Security Policy - SME, at teams vurderer:

“Regulatorisk eksponering (f.eks. GDPR-databehandlerrolle, forpligtelser i den finansielle sektor efter DORA)”

Fra afsnittet “Governancekrav”, politikklausul 5.2.4.

Den fastsætter også et klart krav før deling:

“Databehandleraftaleklausuler eller tilsvarende kontraktlige vilkår skal være aftalt, før personoplysninger eller følsomme data deles.”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.3.2.

Det er forskellen på at have leverandørkontrakter og at have revisionsbar styring af databeskyttelsesroller.

Kortlæg kontroller til rolle, risiko, lovgivning og kontrakt

Zenith Blueprint, risikostyringsfasen, trin 13: planlægning af risikobehandling og anvendelighedserklæring, forklarer den centrale anvendelighedslogik. Kontroller er anvendelige på grund af beslutninger om risikobehandling, juridiske eller kontraktlige krav, relevans for omfanget og organisatorisk kontekst. Udelukkelser kræver klare begrundelser, og anvendelige kontroller bør kunne spores tilbage til en risiko eller et krav.

I trin 13 angiver Zenith Blueprint:

“Sørg for sammenhæng med jeres risikoregister: hver risikoreducerende kontrol, I har skrevet ind i risikobehandlingsplanen, bør svare til en Annex A-kontrol markeret som ‘Applicable’. Omvendt bør I have enten en risiko eller et krav, der driver den, hvis en kontrol er markeret som anvendelig.”

For ISO 27701 anvendes den samme metode på databeskyttelseskontroller. En kontrol kan være anvendelig, fordi:

1. GDPR kræver den for organisationens rolle.
2. En kundekontrakt, databehandleraftale eller ordning mellem fælles dataansvarlige kræver den.
3. En risikobehandling vedrørende databeskyttelse kræver den.
4. Behandlingen omfatter særlige kategorier af personoplysninger, børnedata, overvågning i stor skala, følsom profilering eller PII med højt konsekvensniveau.
5. Leverandør-, cloud-, underdatabehandler- eller grænseoverskridende overførselsrisiko gør kontrollen nødvendig.
6. Kontrollen understøtter certificeringsomfang, revisionsberedskab eller godkendte databeskyttelsesmål.

Legal and Regulatory Compliance Policy understøtter denne kortlægningsdisciplin:

“Hvor en regulering gælder på tværs af flere områder (f.eks. GDPR gælder for opbevaring, sikkerhed og databeskyttelse), skal dette kortlægges tydeligt i efterlevelsesregisteret og træningsmaterialet.”

Fra afsnittet “Governancekrav”, politikklausul 5.2.2.

Den samme Legal and Regulatory Compliance Policy er eksplicit for integration i enterprise-ISMS:

“Alle retlige og regulatoriske forpligtelser skal kortlægges til specifikke politikker, kontroller og ejere i ledelsessystemet for informationssikkerhed (ISMS).”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.2.1.

REG03 bør derfor aldrig være et løsrevet databeskyttelsesregneark. Det bør forbinde behandlingsaktiviteter, retlige forpligtelser, risikobehandlinger, kontrakter, ISO/IEC 27001:2022-kontroller og ejere af bevismateriale.

Praktisk eksempel: en SaaS-supportproces

Overvej en supportproces i Marias SaaS-platform. Kunder opretter tickets, der kan indeholde navne, e-mailadresser, konto-id’er, screenshots og lejlighedsvis følsom forretningskontekst. Supportmedarbejdere får adgang til begrænsede registreringer. En cloudbaseret ticketing-udbyder hoster dataene og bruger egne underdatabehandlere.

Trin 1: Registrér aktiviteten i REG02

Den databeskyttelsesansvarlige registrerer:

• Aktivitetsnavn: Håndtering af kundesupporttickets
• PII-kategorier: brugeridentifikatorer, kontaktoplysninger, screenshots, kontometadata
• Registrerede: kundeadministratorer og slutbrugere
• Formål: support og fejlsøgning af tjenester
• Rolle: databehandler for PII om slutbrugere leveret af kunden, dataansvarlig for direkte styring af forretningskontakter, hvis oplysningerne bruges til kontokommunikation
• Opbevaring: defineret opbevaringsperiode for support og revision
• Modtagere: interne supportmedarbejdere, ticketing-leverandør, godkendte underdatabehandlere
• Sikkerhedsklassificering: Fortrolig, PII

Data Protection and Privacy Policy - SME understøtter denne baseline:

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

Fra afsnittet “Governancekrav”, politikklausul 5.2.1.

Trin 2: Klassificér leverandøren i REG08

Hvis Marias virksomhed er databehandler for kundedata, er ticketing-udbyderen typisk underdatabehandler for disse kundedata. REG08 bør registrere relationstype, kontraktstatus, datakategorier, datalokationer, underliggende underdatabehandlere og assurance-dokumentation.

Trin 3: Registrér REG03-anvendelighed

Enterprise-Data Protection and Privacy Policy tilføjer en højrisiko-udløser:

“Trusselmodellering og konsekvensanalyser vedrørende databeskyttelse (DPIA’er) er obligatoriske for højrisikobehandlingssystemer.”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.3.4.

Data Protection and Privacy Policy - SME indarbejder forventningen om design:

“Databeskyttelse gennem design og standardindstillinger skal håndhæves i alle nye systemer og tjenester”

Fra afsnittet “Governancekrav”, politikklausul 5.3.1.

Trin 4: Tilpas til ISO/IEC 27001:2022-kontroller

Hvis supportplatformen er omfattet af ISMS-omfanget, bør SoA omfatte understøttende ISO/IEC 27002:2022-kontroller såsom leverandørrelationer, leverandøraftaler, styring af IKT-forsyningskæden, adgangsstyring, identitetsstyring, overførsel af information, cloudtjenester, hændelsesstyring, logning og overvågning, ændringsstyring, juridisk efterlevelse og beskyttelse af personoplysninger.

Zenith Blueprint, risikostyringsfasen, trin 14: politikker for risikobehandling og regulatoriske krydshenvisninger, anbefaler krydshenvisning af GDPR, NIS2 og DORA til politikker og kontroller, især for beskyttelse af personoplysninger, hændelseshåndtering, adgangsstyring, forretningskontinuitet og tredjeparts-IKT-risiko.

Resultatet er genanvendeligt bevismateriale, ikke separate regneark for GDPR, DORA, NIS2 og certificering.

Hvad Zenith Controls tilfører PIMS-anvendelighed

Zenith Controls er Clarysecs vejledning i efterlevelse på tværs af krav til forståelse af relationer mellem ISO/IEC 27001:2022- og ISO/IEC 27002:2022-kontroller, revisionsmetoder og andre rammeværker. Det er ikke et særskilt kontrolsæt. For dette emne er de centrale ISO/IEC 27002:2022-kontroller:

• 5.34 Privacy and protection of PII
• 5.19 Information security in supplier relationships
• 5.20 Addressing information security within supplier agreements
• 5.21 Managing information security in the ICT supply chain
• 5.22 Monitoring, review and change management of supplier services

For 5.34 klassificerer Zenith Controls kontrollen som forebyggende, kortlagt til fortrolighed, integritet og tilgængelighed, tilpasset Identify og Protect og knyttet til kapabiliteter inden for informationsbeskyttelse, jura og efterlevelse.

Dens GDPR-kortlægning angiver:

“Implementering af 5.34 er direkte bevismateriale for en organisations evne til at opfylde GDPR’s ansvarlighedskrav.”

Fra Zenith Controls, Privacy and Protection of PII, GDPR-krydskortlægning.

Den sætning er vigtig, fordi den gør 5.34 fra en generisk databeskyttelseserklæring til revisionsbevismateriale. Den bør understøttes af PII-fortegnelser, klassificering, adgangsstyring, maskering, sikker overførsel, cloud-governance, DPIA’er, privatlivsmeddelelser, DSAR-processer og håndtering af brud.

Zenith Controls forbinder også databeskyttelse og PII-beskyttelse med relaterede standarder såsom ISO/IEC 27018 for behandling af PII i public cloud, ISO/IEC 29100 for principper for databeskyttelse og ISO/IEC 29151 for praksis for PII-beskyttelse. Leverandørstyring af databeskyttelse understøttes af ISO/IEC 27036-familien for leverandørrelationer og sikkerhed i IKT-forsyningskæden samt ISO/IEC 27017 for delt ansvar for cloudsikkerhed.

Leverandør- og underdatabehandlerdokumentation er dér, rollerne mødes

Forpligtelser som dataansvarlig og databehandler mødes ofte ved leverandørgrænsen.

Hvis Marias virksomhed er dataansvarlig, forventer GDPR, at den anvender databehandlere, som kan stille tilstrækkelige garantier. Hvis den er databehandler, forventer kunderne, at den styrer underdatabehandlere, viderefører forpligtelser og leverer assurance. Hvis den er underdatabehandler, arver den forpligtelser gennem kæden.

Det gør ISO/IEC 27002:2022-kontrollerne 5.19 og 5.20 centrale for anvendeligheden af ISO 27701-kontroller.

For 5.19 fremhæver Zenith Controls sikkerhed i leverandørrelationer på tværs af governance-, økosystem- og beskyttelsesdomæner. Den knytter direkte til 5.20 leverandøraftaler, 5.21 sikkerhed i IKT-forsyningskæden, 5.14 overførsel af information, 5.36 efterlevelse af politikker, regler og standarder for informationssikkerhed og 5.10 acceptabel brug af information og andre tilknyttede aktiver.

For 5.20 fremhæver Zenith Controls kontraktlig formalisering. Leverandøraftaler bør definere fortrolighed, underretning ved brud, revisionsrettigheder, godkendelse af underleverandører, sikker overførsel, returnering eller destruktion af data, compliance-forpligtelser og overvågning.

Zenith Blueprint, fasen Controls in Action, trin 23: organisatoriske kontroller, giver en praktisk instruks for underdatabehandlere:

“For hver kritisk leverandør skal I identificere, om de bruger underleverandører (underdatabehandlere), der kan få adgang til jeres data eller systemer. Dokumentér, hvordan jeres informationssikkerhedskrav videreføres til disse parter, enten gennem leverandørens kontraktvilkår eller jeres egne direkte klausuler.”

Revisorer stopper ikke ved: “har I en databehandleraftale?” De spørger, om leverandører er databehandlere, underdatabehandlere, selvstændige dataansvarlige eller fælles dataansvarlige, om godkendelser af underdatabehandlere er dokumenteret, om forpligtelser videreføres, om frister ved brud er tydelige, om der udføres overvågning, og om dokumentation for sletning eller returnering kan fremskaffes.

Efterlevelse på tværs uden overlappende kontrolsystemer

Anvendeligheden af ISO 27701-kontroller bliver mere værdifuld, når den understøtter assurance-dialoger om GDPR, NIS2, DORA, NIST CSF 2.0 og COBIT 2019 fra samme bevisgrundlag.

GDPR driver rollebaserede databeskyttelsesforpligtelser: ansvarlighed for dataansvarlige, databehandlerforpligtelser, behandlingsgrundlag, registreredes rettigheder, sikkerhed, styring af brud og kontrakter.

NIS2 tilføjer cybersikkerhedsrisikostyring, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, håndtering af sårbarheder, adgangsstyring, kryptografi, MFA og træning for væsentlige og vigtige enheder.

DORA gælder fra 17. januar 2025 for finansielle enheder omfattet af forordningen og kræver styring af IKT-risiko, hændelsesrapportering, robusthedstest og styring af IKT-tredjepartsrisiko. SaaS- og IKT-udbydere, der leverer til finansielle enheder, bliver ofte bedt om at levere dokumentation for databeskyttelse, sikkerhed, robusthed, revisionsrettigheder og exit i én assurance-pakke.

NIST CSF 2.0 giver et governancelag gennem GOVERN-funktionen, herunder juridiske, regulatoriske, kontraktlige og databeskyttelsesforpligtelser, roller, risikovillighed, politiktilsyn og styring af forsyningskæden.

COBIT 2019 tilføjer governance- og ledelsespraksis. For databeskyttelse kortlægger Zenith Controls 5.34 til COBIT DSS06.02, DSS06.08 og APO13.01. For leverandører understøtter 5.19 og 5.20 praksis for leverandørrisiko og leverandøraftaler.

Det strategiske punkt er enkelt. REG03 bør være mere end en ISO 27701-artefakt. Det bør være et genanvendeligt kort over kontrollernes anvendelighed til kunderevisioner, regulatoriske gennemgange og assurance på bestyrelsesniveau.

Hvordan revisorer tester anvendeligheden af ISO 27701-kontroller

Forskellige revisorer starter fra forskellige vinkler, men de ender som regel ved samme beviskæde.

En ISO-ledelsessystemrevisor starter med omfang, interessenter, forpligtelser, risikovurdering, SoA-sammenhæng, intern audit, ledelsens evaluering og løbende forbedring. Revisoren vil teste, om REG02, REG03 og ISO/IEC 27001:2022 SoA stemmer overens.

En GDPR-fokuseret revisor eller DPO-gennemgangsansvarlig tester rollelogikken. De vil udtage stikprøver af aktiviteter, gennemgå behandlingsgrundlag, privatlivsmeddelelser, databehandleraftaler, underdatabehandlere, DPIA’er, DSAR-håndtering, opbevaring og beslutninger vedrørende brud.

En NIST-orienteret assessor ser efter governance-resultater, risikokategorisering, datafortegnelser, adgangskontroller, beskyttelse af data i hvile og under overførsel, overvågning, hændelseshåndtering, leverandørrisiko og forbedringsplaner.

En COBIT 2019- eller ISACA-revisor ser på governance-ejerskab, proceskapabilitet, kontroldesign og operationel effektivitet. Revisoren vil teste, om databeskyttelseskontroller er indlejret i indkøb, ændringsstyring, hændelsesstyring og leverandørovervågning.

For 5.34 beskriver Zenith Controls, at revisorer gennemgår databeskyttelsespolitikker, datafortegnelser, DPIA’er, træningslogfiler, tekniske sikkerhedsforanstaltninger, DSAR-stikprøver, PII-hændelser og dokumentation for databeskyttelse gennem design. For 5.19 og 5.20 anmoder revisorer om leverandørfortegnelser, risikoklassificeringer, due diligence-registreringer, kontrakter, vilkår om brud, revisionsrettigheder, godkendelse af underleverandører, exitdokumentation og dokumentation for, at leverandørrapporter gennemgås.

Forskellen er afgørende. Revisionsberedskab er ikke “vi har en klausul”. Revisionsberedskab er “vi brugte klausulen, overvågede den, gennemgik bevismateriale og handlede, da risikoen ændrede sig.”

Almindelige fejl i anvendelighed for dataansvarlige og databehandlere

Clarysec ser gentagne gange fem undgåelige fejl.

For det første klassificerer organisationer hele virksomheden som én GDPR-rolle. Det fungerer ikke for SaaS, fintech, HR tech, health tech, administrerede tjenester eller cloududbydere med blandede dataflows.

For det andet behandler de ISO 27701-kontroller som universelt anvendelige uden rollebegrundelse. Det skaber oppustede krav til bevismateriale og svage udelukkelser.

For det tredje udelukker de kontroller uden at dokumentere hvorfor. I ISO/IEC 27001:2022 SoA-logik og PIMS-logik for anvendelighed skal udelukkelser være bevidste, begrundede og understøttet af analyse af omfang, rolle, risiko eller lovgivning.

For det fjerde glemmer de underdatabehandlere. En databehandlers assurance-fortælling er kun så stærk som den underliggende kæde. Underdatabehandlerregistre, godkendelsesmekanismer, videreførte klausuler og dokumentation for sletning er afgørende.

For det femte undlader de at forbinde databeskyttelseskontroller med sikkerhedsdrift. Databeskyttelse gennem design er ikke blot en DPIA-skabelon. Det bør påvirke adgangskontroller, logning, sikker udvikling, cloudkonfiguration, leverandør-due diligence, automatisering af opbevaring og hændelseshåndtering.

Clarysec-klar tjekliste for REG03-kontrollers anvendelighed

Brug denne tjekliste før ISO 27701-gennemgange af revisionsberedskab, GDPR-kundeassurance eller DORA-drevne leverandørvurderinger:

• Opret eller opdater REG02 for hver behandlingsaktivitet, der omfatter PII.
• Klassificér PIMS-rollen for hver aktivitet, før behandlingen påbegyndes.
• Klassificér hvert tredjepartsforhold i REG08 før kontraktgodkendelse eller PII-behandling.
• Identificér forpligtelser baseret på rolle: dataansvarlig, databehandler, fælles dataansvarlig eller underdatabehandler.
• Registrér anvendelige PIMS-kontroller i REG03 med ejer, implementeringsstatus og bevismateriale.
• Registrér udelukkede kontroller med klar begrundelse.
• Knyt REG03-beslutninger til risici, retlige forpligtelser, kontrakter eller omfangsbegrundelse.
• Tilpas REG03 til ISO/IEC 27001:2022 SoA, hvor sikkerhedskontroller understøtter databeskyttelse.
• Kortlæg databeskyttelseskontroller til ISO/IEC 27002:2022 5.34, hvor PII-beskyttelse kræves.
• Kortlæg leverandør- og underdatabehandlerkrav til 5.19, 5.20, 5.21 og 5.22.
• Tilføj krydshenvisninger for GDPR, NIS2, DORA, NIST CSF 2.0 og COBIT 2019, hvor det er relevant.
• Test beviskæden med en intern revisionsstikprøve før gennemgang af revisionsberedskab til certificering.
• Indhent øverste ledelses godkendelse, når PIMS-omfang eller kontrollernes anvendelighed ændres.

Privacy Information Management System Policy lukker denne governancesløjfe:

“[Begge] Øverste ledelse SKAL godkende ændringer i PIMS-omfang og kontrollernes anvendelighed i REG01 og REG03, før ændringer i certificeringsomfanget indsendes.”

Fra afsnittet “PIMS-governance”, politikklausul 6.1.3.

Det er den type styringsdokumentation, revisorer har tillid til.

Gør GDPR-rollebeslutninger til forsvarligt bevismateriale

Anvendeligheden af ISO 27701-kontroller er dér, GDPR-rolleteori bliver til operationel virkelighed. En dataansvarlig har brug for bevismateriale for behandlingsgrundlag, gennemsigtighed, opbevaring, DPIA’er, håndtering af rettigheder og tilsyn med databehandlere. En databehandler har brug for bevismateriale for dokumenterede instrukser, fortrolighed, sikkerhed, bistand, underdatabehandlere, bistand ved brud og sletning. En fælles dataansvarlig har brug for en gennemsigtig ansvarsordning. En underdatabehandler har brug for videreførte forpligtelser og assurance-understøttelse.

Clarysec hjælper organisationer med at opbygge dette bevislag gennem:

• REG02-struktur for fortegnelse over behandlingsaktiviteter og behandlingsgrundlag.
• REG03-registreringer af PIMS-kontrollers anvendelighed.
• REG08-klassificering af tredjepartsrelationer vedrørende databeskyttelse.
• Tilpasning til ISO/IEC 27001:2022 SoA.
• Politikklausuler, der tildeler ejere, tidskrav og godkendelseskrav.
• Kortlægning på tværs af efterlevelseskrav gennem Zenith Controls.
• Implementeringssekvensering gennem Zenith Blueprint.

Hvis din organisation forbereder sig på ISO 27701 PIMS-beredskab, GDPR-kundeassurance, DORA-leverandørgennemgange eller NIS2-tilpasset sikkerhedsstyring, så begynd med én højrisikobehandlingsaktivitet. Klassificér rollen. Kortlæg de anvendelige kontroller. Knyt bevismaterialet sammen. Gentag derefter, indtil jeres databeskyttelsesprogram ikke kun er compliant på papiret, men kan forklares under revision.

Download Clarysecs PIMS-politikpakke, udforsk Zenith Blueprint, eller book en Clarysec-gennemgang af revisionsberedskab for at omsætte beslutninger om dataansvarlige, databehandlere, fælles dataansvarlige og underdatabehandlere til et certificeringsklart register over bevismateriale for databeskyttelse.