+Člen 4 Opredelitev pojmov

Člen 4 Opredelitev pojmov

Člen 4

Opredelitev pojmov

V tej uredbi:

(1) 

„osebni podatki“ pomeni katero koli informacijo v zvezi z določenim ali določljivim posameznikom (v nadaljnjem besedilu: posameznik, na katerega se nanašajo osebni podatki); določljiv posameznik je tisti, ki ga je mogoče neposredno ali posredno določiti, zlasti z navedbo identifikatorja, kot je ime, identifikacijska številka, podatki o lokaciji, spletni identifikator, ali z navedbo enega ali več dejavnikov, ki so značilni za fizično, fiziološko, genetsko, duševno, gospodarsko, kulturno ali družbeno identiteto tega posameznika;

(2) 

„obdelava“ pomeni vsako dejanje ali niz dejanj, ki se izvaja v zvezi z osebnimi podatki ali nizi osebnih podatkov z avtomatiziranimi sredstvi ali brez njih, kot je zbiranje, beleženje, urejanje, strukturiranje, shranjevanje, prilagajanje ali spreminjanje, priklic, vpogled, uporaba, razkritje s posredovanjem, razširjanje ali drugačno omogočanje dostopa, prilagajanje ali kombiniranje, omejevanje, izbris ali uničenje;

(3) 

„omejitev obdelave“ pomeni označevanje shranjenih osebnih podatkov zaradi omejevanja njihove obdelave v prihodnosti;

(4) 

„oblikovanje profilov“ pomeni vsako obliko avtomatizirane obdelave osebnih podatkov, ki vključuje uporabo osebnih podatkov za ocenjevanje nekaterih osebnih vidikov v zvezi s posameznikom, zlasti za analizo ali predvidevanje uspešnosti pri delu, ekonomskega položaja, zdravja, osebnega okusa, interesov, zanesljivosti, vedenja, lokacije ali gibanja tega posameznika;

(5) 

„psevdonimizacija“ pomeni obdelavo osebnih podatkov na tak način, da osebnih podatkov brez dodatnih informacij ni več mogoče pripisati specifičnemu posamezniku, na katerega se nanašajo osebni podatki, če se take dodatne informacije hranijo ločeno ter zanje veljajo tehnični in organizacijski ukrepi za zagotavljanje, da se osebni podatki ne pripišejo določenemu ali določljivemu posamezniku;

(6) 

„zbirka“ pomeni vsak strukturiran niz osebnih podatkov, ki so dostopni v skladu s posebnimi merili, niz pa je lahko centraliziran, decentraliziran ali razpršen na funkcionalni ali geografski podlagi;

(7) 

„upravljavec“ pomeni fizično ali pravno osebo, javni organ, agencijo ali drugo telo, ki samo ali skupaj z drugimi določa namene in sredstva obdelave; kadar namene in sredstva obdelave določa pravo Unije ali pravo države članice, se lahko upravljavec ali posebna merila za njegovo imenovanje določijo s pravom Unije ali pravom države članice;

(8) 

„obdelovalec“ pomeni fizično ali pravno osebo, javni organ, agencijo ali drugo telo, ki obdeluje osebne podatke v imenu upravljavca;

(9) 

„uporabnik“ pomeni fizično ali pravno osebo, javni organ, agencijo ali drugo telo, ki so mu bili osebni podatki razkriti, ne glede na to, ali je tretja oseba ali ne. Vendar pa se javni organi, ki lahko prejmejo osebne podatke v okviru posamezne poizvedbe v skladu s pravom Unije ali pravom države članice, ne štejejo za uporabnike; obdelava teh podatkov s strani teh javnih organov poteka v skladu z veljavnimi pravili o varstvu podatkov glede na namene obdelave;

(10) 

„tretja oseba“ pomeni fizično ali pravno osebo, javni organ, agencijo ali telo, ki ni posameznik, na katerega se nanašajo osebni podatki, upravljavec, obdelovalec in osebe, ki so pooblaščene za obdelavo osebnih podatkov pod neposrednim vodstvom upravljavca ali obdelovalca;

▼C1

(11) 

„privolitev“ posameznika, na katerega se nanašajo osebni podatki, pomeni vsako prostovoljno, konkretno, informirano in nedvoumno ravnanje v obliki izjave ali jasnega pritrdilnega dejanja, iz katerega je mogoče sklepati na želje posameznika, na katerega se nanašajo osebni podatki, s katerim izrazi strinjanje z obdelavo osebnih podatkov, ki se nanašajo nanj;

▼B

(12) 

„ ►C1  kršitev varnosti osebnih podatkov ◄ “ pomeni kršitev varnosti, ki povzroči nenamerno ali nezakonito uničenje, izgubo, spremembo, nepooblaščeno razkritje ali dostop do osebnih podatkov, ki so poslani, shranjeni ali kako drugače obdelani;

▼C1

(13) 

„genski podatki“ pomeni osebne podatke v zvezi s podedovanimi ali pridobljenimi genetskimi značilnostmi posameznika, ki dajejo edinstvene informacije o fiziologiji ali zdravju tega posameznika in so zlasti rezultat analize biološkega vzorca zadevnega posameznika;

▼B

(14) 

„biometrični podatki“ pomeni osebne podatke, ki so rezultat posebne tehnične obdelave v zvezi s fizičnimi, fiziološkimi ali vedenjskimi značilnostmi posameznika, ki omogočajo ali potrjujejo edinstveno identifikacijo tega posameznika, kot so podobe obraza ali daktiloskopski podatki;

(15) 

„podatki o zdravstvenem stanju“ pomeni osebne podatke, ki se nanašajo na telesno ali duševno zdravje posameznika, vključno z zagotavljanjem zdravstvenih storitev, in razkrivajo informacije o njegovem zdravstvenem stanju;

(16) 

„glavna ►C1  ustanovitev ◄ “ pomeni:

(a) 

v zvezi z upravljavcem, ki ima ►C1  ustanovitve ◄ v več kot eni državi članici, kraj njegove osrednje uprave v Uniji ali, kadar se odločitve o namenih in sredstvih obdelave osebnih podatkov sprejemajo na drugi ►C1  ustanovitvi ◄ upravljavca v Uniji in ima ta ►C1  ustanovitev ◄ pooblastila za izvajanje takih odločitev, ►C1  ustanovitev ◄ , ki sprejema take odločitve;

(b) 

v zvezi z obdelovalcem, ki ima ►C1  ustanovitve ◄ v več kot eni državi članici, kraj njegove osrednje uprave v Uniji ali, če obdelovalec nima osrednje uprave v Uniji, ►C1  ustanovitev ◄ obdelovalca v Uniji, kjer se izvajajo glavne dejavnosti obdelave v okviru dejavnosti ►C1  ustanovitve ◄ obdelovalca, kolikor za obdelovalca veljajo posebne obveznosti iz te uredbe;

(17) 

„predstavnik“ pomeni fizično ali pravno osebo z ►C1  ustanovitvijo ◄ v Uniji, ki jo pisno imenuje upravljavec ali obdelovalec v skladu s členom 27 in ki predstavlja upravljavca ali obdelovalca v zvezi z njegovimi obveznostmi iz te uredbe;

(18) 

„podjetje“ pomeni fizično ali pravno osebo, ki opravlja gospodarsko dejavnost, ne glede na njeno pravno obliko, vključno s partnerstvi ali združenji, ki redno opravljajo gospodarsko dejavnost;

(19) 

„povezana družba“ pomeni obvladujočo družbo in njene odvisne družbe;

(20) 

„zavezujoča poslovna pravila“ pomeni politike na področju varstva osebnih podatkov, ki jih upravljavec ali obdelovalec z ►C1  ustanovitvijo ◄ na ozemlju države članice spoštuje pri prenosih ali nizih prenosov osebnih podatkov upravljavcu ali obdelovalcu povezane družbe ali skupine podjetij, ki opravljajo skupno gospodarsko dejavnost, v eni ali več tretjih državah;

(21) 

„nadzorni organ“ pomeni neodvisen javni organ, ki ga v skladu s členom 51 ustanovi država članica;

(22) 

„zadevni nadzorni organ“ pomeni nadzorni organ, ki ga obdelava osebnih podatkov zadeva, ker:

(a) 

ima upravljavec ali obdelovalec ►C1  ustanovitev ◄ na ozemlju države članice tega nadzornega organa;

(b) 

obdelava znatno vpliva ali bi lahko znatno vplivala na posameznike, na katere se nanašajo osebni podatki, s prebivališčem v državi članici tega nadzornega organa, ali

(c) 

je bila vložena pritožba pri tem nadzornem organu;

(23) 

„čezmejna obdelava osebnih podatkov“ pomeni bodisi:

(a) 

obdelavo osebnih podatkov, ki poteka v Uniji v okviru dejavnosti ►C1  ustanovitev ◄ upravljavca ali obdelovalca v več kot eni državi članici, kadar ima upravljavec ali obdelovalec ►C1  ustanovitev ◄ v več kot eni državi članici, bodisi

(b) 

obdelavo osebnih podatkov, ki poteka v Uniji v okviru dejavnosti edine ►C1  ustanovitve ◄ upravljavca ali obdelovalca, vendar obdelava znatno vpliva ali bi lahko znatno vplivala na posameznike, na katere se nanašajo osebni podatki, v več kot eni državi članici;

(24) 

„ustrezen in utemeljen ugovor“ pomeni ugovor osnutku odločitve glede tega, ali je bila uredba kršena, oziroma glede tega, ali je predvideno ukrepanje v zvezi z upravljavcem ali obdelovalcem v skladu s to uredbo, kar jasno navede pomen tveganja, ki ga predstavlja osnutek odločitve, kar zadeva temeljne pravice in svoboščine posameznikov, na katere se nanašajo osebni podatki, in – kjer je to ustrezno – prosti pretok osebnih podatkov v Uniji;

(25) 

„storitev informacijske družbe“ pomeni storitev, kakor je opredeljena v točki (b) člena 1(1) Direktive (EU) 2015/1535 Evropskega parlamenta in Sveta ( 1 );

(26) 

„mednarodna organizacija“ pomeni organizacijo in njena podrejena telesa, ki jih ureja mednarodno javno pravo ali kateri koli drugo telo, ustanovljeno s sporazumom med dvema ali več državami ali na podlagi takega sporazuma.

1. Pregled

,
Naslov Regulativa

1.1 Sklici

1.2 Ugotovljene zahteve

1.3 Povezani standardi

2. Ugotovljene zahteve

Zahteve
Vir Zahteva

3. Povezani standardi

Standardi
Vir Zahteva
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.