+Artikel 4 Definitioner

Artikel 4 Definitioner

Artikel 4

Definitioner

I denne forordning forstås ved:

1)

»personoplysninger« : enhver form for information om en identificeret eller identificerbar fysisk person (»den registrerede«); ved identificerbar fysisk person forstås en fysisk person, der direkte eller indirekte kan identificeres, navnlig ved en identifikator som f.eks. et navn, et identifikationsnummer, lokaliseringsdata, en onlineidentifikator eller et eller flere elementer, der er særlige for denne fysiske persons fysiske, fysiologiske, genetiske, psykiske, økonomiske, kulturelle eller sociale identitet

2)

»behandling« : enhver aktivitet eller række af aktiviteter — med eller uden brug af automatisk behandling — som personoplysninger eller en samling af personoplysninger gøres til genstand for, f.eks. indsamling, registrering, organisering, systematisering, opbevaring, tilpasning eller ændring, genfinding, søgning, brug, videregivelse ved transmission, formidling eller enhver anden form for overladelse, sammenstilling eller samkøring, begrænsning, sletning eller tilintetgørelse

3)

»begrænsning af behandling« : mærkning af opbevarede personoplysninger med den hensigt at begrænse fremtidig behandling af disse oplysninger

4)

»profilering« : enhver form for automatisk behandling af personoplysninger, der består i at anvende personoplysninger til at evaluere bestemte personlige forhold vedrørende en fysisk person, navnlig for at analysere eller forudsige forhold vedrørende den fysiske persons arbejdsindsats, økonomiske situation, helbred, personlige præferencer, interesser, pålidelighed, adfærd, geografisk position eller bevægelser

5)

»pseudonymisering« : behandling af personoplysninger på en sådan måde, at personoplysningerne ikke længere kan henføres til en bestemt registreret uden brug af supplerende oplysninger, forudsat at sådanne supplerende oplysninger opbevares separat og er underlagt tekniske og organisatoriske foranstaltninger for at sikre, at personoplysningerne ikke henføres til en identificeret eller identificerbar fysisk person

6)

»register« : enhver struktureret samling af personoplysninger, der er tilgængelig efter bestemte kriterier, hvad enten denne samling er placeret centralt eller decentralt eller er fordelt på funktionsbestemt eller geografisk grundlag

7)

»dataansvarlig« : en fysisk eller juridisk person, en offentlig myndighed, en institution eller et andet organ, der alene eller sammen med andre afgør, til hvilke formål og med hvilke hjælpemidler der må foretages behandling af personoplysninger; hvis formålene og hjælpemidlerne til en sådan behandling er fastlagt i EU-retten eller medlemsstaternes nationale ret, kan den dataansvarlige eller de specifikke kriterier for udpegelse af denne fastsættes i EU-retten eller medlemsstaternes nationale ret

8)

»databehandler« : en fysisk eller juridisk person, en offentlig myndighed, en institution eller et andet organ, der behandler personoplysninger på den dataansvarliges vegne

9)

»modtager« : en fysisk eller juridisk person, en offentlig myndighed, en institution eller et andet organ, hvortil personoplysninger videregives, uanset om det er en tredjemand eller ej. Offentlige myndigheder, som vil kunne få meddelt personoplysninger som led i en isoleret forespørgsel i henhold til EU-retten eller medlemsstaternes nationale ret, anses dog ikke for modtagere; de offentlige myndigheders behandling af disse oplysninger skal overholde de gældende databeskyttelsesregler afhængigt af formålet med behandlingen

10)

»tredjemand« : en anden fysisk eller juridisk person, offentlig myndighed eller institution eller ethvert andet organ end den registrerede, den dataansvarlige, databehandleren og de personer under den dataansvarliges eller databehandlerens direkte myndighed, der er beføjet til at behandle personoplysninger

11)

»samtykke« fra den registrerede : enhver frivillig, specifik, informeret og utvetydig viljestilkendegivelse fra den registrerede, hvorved den registrerede ved erklæring eller klar bekræftelse indvilliger i, at personoplysninger, der vedrører den pågældende, gøres til genstand for behandling

12)

»brud på persondatasikkerheden« : et brud på sikkerheden, der fører til hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger, der er transmitteret, opbevaret eller på anden måde behandlet

13)

»genetiske data« : personoplysninger vedrørende en fysisk persons arvede eller erhvervede genetiske karakteristika, som giver entydig information om den fysiske persons fysiologi eller helbred, og som navnlig foreligger efter en analyse af en biologisk prøve fra den pågældende fysiske person

14)

»biometriske data« : personoplysninger, der som følge af specifik teknisk behandling vedrørende en fysisk persons fysiske, fysiologiske eller adfærdsmæssige karakteristika muliggør eller bekræfter en entydig identifikation af vedkommende, f.eks. ansigtsbillede eller fingeraftryksoplysninger

15)

»helbredsoplysninger« : personoplysninger, der vedrører en fysisk persons fysiske eller mentale helbred, herunder levering af sundhedsydelser, og som giver information om vedkommendes helbredstilstand

16)

»hovedvirksomhed« :

a) 

for så vidt angår en dataansvarlig som er etableret i mere end én medlemsstat, stedet for dennes centrale administration i Unionen, medmindre beslutninger vedrørende formål og hjælpemidler i forbindelse med behandling af personoplysninger træffes i en anden af den dataansvarliges etableringer i Unionen, og sidstnævnte etablering har beføjelse til få sådanne beslutninger gennemført; i så fald anses den etablering, der har truffet sådanne beslutninger, for hovedvirksomheden

b) 

for så vidt angår en databehandler som er etableret i mere end én medlemsstat, stedet for dennes centrale administration i Unionen, eller, hvis denne ikke har en central administration i Unionen, den etablering i Unionen, hvor databehandlerens hovedbehandlingsaktiviteter foretages i databehandlerens egenskab af at være databehandler, i det omfang databehandleren er underlagt specifikke forpligtelser i henhold til denne forordning

17)

»repræsentant« : en fysisk eller juridisk person, der er etableret i Unionen, som skriftligt er udpeget af den dataansvarlige eller databehandleren i henhold til artikel 27, og som repræsenterer den dataansvarlige eller databehandleren hvad angår deres respektive forpligtelser i medfør af denne forordning

18)

»foretagende« : en fysisk eller juridisk person, som udøver økonomisk aktivitet, uanset dens retlige status, herunder partnerskaber eller sammenslutninger, der regelmæssigt udøver økonomisk aktivitet

19)

»koncern« : en virksomhed, der udøver kontrol, og de af denne kontrollerede virksomheder

20)

»bindende virksomhedsregler« : regler om beskyttelse af personoplysninger, som en dataansvarlig eller databehandler, der er etableret på en medlemsstats område, overholder i forbindelse med overførsel eller en række overførsler af personoplysninger til en dataansvarlig eller databehandler i et eller flere tredjelande inden for en koncern eller gruppe af foretagender, der udøver en fælles økonomisk aktivitet

21)

»tilsynsmyndighed« : en uafhængig offentlig myndighed, der er etableret i en medlemsstat i henhold til artikel 51

22)

»berørt tilsynsmyndighed« :

en tilsynsmyndighed, der er berørt af en behandling af personoplysninger, fordi:

a) 

den dataansvarlige eller databehandleren er etableret på denne tilsynsmyndigheds medlemsstats område

b) 

de registrerede, der har bopæl i denne tilsynsmyndigheds medlemsstat, i væsentlig grad er påvirket af eller sandsynligvis i væsentlig grad vil kunne blive påvirket af behandlingen, eller

c) 

en klage er blevet indgivet til denne tilsynsmyndighed

23)

»grænseoverskridende behandling« :

a) 

behandling af personoplysninger, der finder sted som led i aktiviteter, som udføres for en dataansvarligs eller en databehandlers virksomheder i mere end én medlemsstat i Unionen, hvor den dataansvarlige eller databehandleren er etableret i mere end én medlemsstat, eller

b) 

behandling af personoplysninger, der finder sted som led i aktiviteter, som udføres for en dataansvarligs eller en databehandlers eneste etablering i Unionen, men som i væsentlig grad påvirker eller sandsynligvis i væsentlig grad vil kunne påvirke registrerede i mere end én medlemsstat

24)

»relevant og begrundet indsigelse« : en indsigelse mod et udkast til afgørelse om, hvorvidt der foreligger en overtrædelse af denne forordning, eller hvorvidt en planlagt foranstaltning i forbindelse med den dataansvarlige eller databehandleren overholder denne forordning, og som klart påviser betydningen af de risici, som udkastet til afgørelse udgør for registreredes grundlæggende rettigheder og frihedsrettigheder og, hvis det er relevant, for den frie udveksling af personoplysninger i Unionen

25)

»informationssamfundstjeneste« : en tjeneste som defineret i artikel 1, stk. 1, litra b), i Europa-Parlamentets og Rådets direktiv (EU) 2015/1535 ( 1 )

26)

»international organisation« : en folkeretlig organisation og organer, der er underordnet den, samt ethvert andet organ, der er oprettet ved eller med hjemmel i en aftale mellem to eller flere lande.

1. Oversigt

,
Titel Regulering

1.1 Referencer

1.2 Identificerede krav

1.3 Relaterede standarder

2. Identificerede krav

Krav
Kilde Krav

3. Relaterede standarder

Standarder
Kilde Krav
SCF Achieving Security, Compliance & Resilience Requirements

Description

Mechanisms exist to design Technology Assets, Applications and/or Services (TAAS) so that required capabilities continue to operate in a controlled and acceptable manner, when conditions are both routine and degraded.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.

Level 2 Planned Tracked

Secure Engineering & Architecture (SEA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.
▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.
▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).

Level 3 Well Defined

Secure Engineering & Architecture (SEA) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.
▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with SEA domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).
▪ An implemented and operational capability exists to achieve resilience requirements in normal and adverse situations.

Level 4 Quantitatively Controlled

Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.

Level 5 Continuously Improving

Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
SCF Standardized Terminology

Description

Mechanisms exist to standardize technology and process terminology to reduce confusion amongst groups and departments.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Follow secure coding basics when developing software

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Secure coding guidelines for developers
∙ Basic security review before release

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Formal security engineering principles
∙ Secure design patterns
∙ Threat modeling

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Enterprise security engineering program
∙ Formal threat modeling
∙ Security architecture standards

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Enterprise security architecture framework (SABSA)
∙ Formal threat modeling program
∙ Security design patterns library

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

SCR-CMM Level 1 criteria definitions are not available for this control:
▪ A reasonable person would conclude this control requires a structured process.
▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality.

Level 2 Planned Tracked

Secure Engineering & Architecture (SEA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.
▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.
▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).

Level 3 Well Defined

Cybersecurity & Data Protection Governance (GOV) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).
▪ An implemented and operational capability exists to standardize technology and process terminology to reduce confusion amongst groups and departments.

Level 4 Quantitatively Controlled

Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.

Level 5 Continuously Improving

Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.