+Άρθρο 19 Υποχρεώσεις των εισαγωγέων
---+Άρθρο 19 1.
---+Άρθρο 19 2.
---+Άρθρο 19 3.
---+Άρθρο 19 4.
---+Άρθρο 19 5.
---+Άρθρο 19 6.
---+Άρθρο 19 7.
---+Άρθρο 19 8.

Άρθρο 19 Υποχρεώσεις των εισαγωγέων

1. Επισκόπηση

,

Τίτλος	Κανονισμός
Άρθρο 19 1.	Οι εισαγωγείς θέτουν σε κυκλοφορία στην αγορά μόνο προϊόντα με ψηφιακά στοιχεία που συμμορφώνονται προς τις ουσιώδεις απαιτήσεις κυβερνοασφάλειας που ορίζονται στο παράρτημα I μέρος I, και εφόσον οι διαδικασίες που εφαρμόζει ο κατασκευαστής συμμορφώνονται προς τις ουσιώδεις απαιτήσεις κυβερνοασφάλειας που ορίζονται στο παράρτημα I μέρος II.
Άρθρο 19 2.	Προτού θέσουν σε κυκλοφορία στην αγορά προϊόν με ψηφιακά στοιχεία, οι εισαγωγείς διασφαλίζουν τα εξής: α) ο κατασκευαστής έχει διενεργήσει τις κατάλληλες διαδικασίες αξιολόγησης της συμμόρφωσης όπως αναφέρονται στο άρθρο 32· β) ο κατασκευαστής έχει καταρτίσει τεχνικό φάκελο· γ) το προϊόν με ψηφιακά στοιχεία φέρει τη σήμανση CE που αναφέρεται στο άρθρο 30 και συνοδεύεται από τη δήλωση συμμόρφωσης ΕΕ, που αναφέρεται στο άρθρο 13 παράγραφος 20, και τις πληροφορίες και οδηγίες προς τον χρήστη, όπως ορίζονται στο παράρτημα II, σε γλώσσα εύκολα κατανοητή από τους χρήστες και τις αρχές εποπτείας της αγοράς· δ) ο κατασκευαστής έχει συμμορφωθεί με τις απαιτήσεις που καθορίζονται στο άρθρο 13 παράγραφοι 15, 16 και 19. Για τους σκοπούς της παρούσας παραγράφου, οι εισαγωγείς πρέπει να είναι σε θέση να προσκομίσουν τα αναγκαία έγγραφα που αποδεικνύουν την εκπλήρωση των απαιτήσεων που ορίζονται στο παρόν άρθρο.
Άρθρο 19 3.	Όταν ένας εισαγωγέας θεωρεί ή έχει λόγους να πιστεύει ότι ένα προϊόν με ψηφιακά στοιχεία ή οι διαδικασίες που εφαρμόζει ο κατασκευαστής δεν συμμορφώνονται με τον παρόντα κανονισμό, ο εισαγωγέας δεν θέτει το προϊόν σε κυκλοφορία στην αγορά έως ότου το εν λόγω προϊόν ή οι διαδικασίες που εφαρμόζει ο κατασκευαστής συμμορφωθούν με τον παρόντα κανονισμό. Επιπλέον, όταν το προϊόν με ψηφιακά στοιχεία παρουσιάζει σημαντικό κίνδυνο για την κυβερνοασφάλεια, ο εισαγωγέας ενημερώνει σχετικά τον κατασκευαστή και τις αρχές εποπτείας της αγοράς. Όταν ένας εισαγωγέας θεωρεί ή έχει λόγους να πιστεύει ότι ένα προϊόν με ψηφιακά στοιχεία μπορεί να παρουσιάζει σημαντικό κίνδυνο κυβερνοασφάλειας λόγω μη τεχνικών παραγόντων κινδύνου, ο εισαγωγέας ενημερώνει σχετικά τις αρχές εποπτείας της αγοράς. Μόλις λάβουν τις εν λόγω πληροφορίες, οι αρχές εποπτείας της αγοράς ακολουθούν τις διαδικασίες που αναφέρονται στο άρθρο 54 παράγραφος 2.
Άρθρο 19 4.	Οι εισαγωγείς αναγράφουν το όνομα, την καταχωρισμένη εμπορική επωνυμία ή το καταχωρισμένο εμπορικό σήμα, την ταχυδρομική διεύθυνση, τη διεύθυνση ηλεκτρονικού ταχυδρομείου ή άλλα ψηφιακά στοιχεία επικοινωνίας τους, καθώς και, κατά περίπτωση, τον ιστότοπο μέσω του οποίου μπορεί κανείς να επικοινωνήσει μαζί τους, στο προϊόν με ψηφιακά στοιχεία ή στη συσκευασία του ή σε έγγραφο που συνοδεύει το προϊόν με ψηφιακά στοιχεία. Τα στοιχεία επικοινωνίας παρέχονται σε γλώσσα εύκολα κατανοητή από τους χρήστες και τις αρχές εποπτείας της αγοράς.
Άρθρο 19 5.	Οι εισαγωγείς που γνωρίζουν ή έχουν λόγο να πιστεύουν ότι προϊόν με ψηφιακά στοιχεία που έχουν θέσει σε κυκλοφορία στην αγορά δεν συμμορφούται προς τον παρόντα κανονισμό λαμβάνουν αμέσως τα αναγκαία διορθωτικά μέτρα για να εξασφαλίσουν τη συμμόρφωση του προϊόντος με τον παρόντα κανονισμό, ή για να αποσύρουν ή να ανακαλέσουν το προϊόν, κατά περίπτωση. Αμέσως μόλις αντιληφθούν την ύπαρξη ευπάθειας στο προϊόν με ψηφιακά στοιχεία, οι εισαγωγείς ενημερώνουν τον κατασκευαστή χωρίς αδικαιολόγητη καθυστέρηση σχετικά με την εν λόγω ευπάθεια. Πέραν τούτου, όταν το προϊόν με ψηφιακά στοιχεία ενέχει σημαντικό κίνδυνο για την κυβερνοασφάλεια, οι εισαγωγείς ενημερώνουν αμέσως σχετικά με το θέμα αυτό τις αρχές εποπτείας της αγοράς των κρατών μελών στην αγορά των οποίων κατέστησαν διαθέσιμο το προϊόν με ψηφιακά στοιχεία, και παραθέτουν λεπτομέρειες, συγκεκριμένα, για τη μη συμμόρφωση και τα τυχόν διορθωτικά μέτρα που έλαβαν.
Άρθρο 19 6.	Οι εισαγωγείς τηρούν τουλάχιστον επί δέκα έτη αφότου το προϊόν με ψηφιακά στοιχεία τεθεί σε κυκλοφορία στην αγορά ή για την περίοδο υποστήριξης, ανάλογα με το ποιο διάστημα είναι μεγαλύτερο, αντίγραφο της δήλωσης συμμόρφωσης ΕΕ στη διάθεση των αρχών εποπτείας της αγοράς και εξασφαλίζουν ότι ο τεχνικός φάκελος μπορεί να τεθεί στη διάθεση των εν λόγω αρχών, κατόπιν αιτήματός τους.
Άρθρο 19 7.	Οι εισαγωγείς παρέχουν στην αρχή εποπτείας της αγοράς, κατόπιν αιτιολογημένου αιτήματος της εν λόγω αρχής, όλες τις πληροφορίες και την τεκμηρίωση, σε έντυπη ή σε ηλεκτρονική μορφή, που απαιτούνται για να αποδειχθεί η συμμόρφωση του προϊόντος με ψηφιακά στοιχεία προς τις ουσιώδεις απαιτήσεις κυβερνοασφάλειας που ορίζονται στο παράρτημα I μέρος I, καθώς και των διαδικασιών που εφαρμόζει ο κατασκευαστής προς τις ουσιώδεις απαιτήσεις κυβερνοασφάλειας που ορίζονται στο παράρτημα I μέρος II, σε γλώσσα εύκολα κατανοητή από την εν λόγω αρχή. Συνεργάζονται με την εν λόγω αρχή, κατόπιν αιτήματος της, όσον αφορά τη λήψη μέτρων για την εξάλειψη των κινδύνων κυβερνοασφάλειας τους οποίους ενέχουν τα προϊόντα με ψηφιακά στοιχεία που έχουν θέσει σε κυκλοφορία στην αγορά.
Άρθρο 19 8.	Όταν ο εισαγωγέας προϊόντος με ψηφιακά στοιχεία αντιληφθεί ότι ο κατασκευαστής του εν λόγω προϊόντος έπαυσε τις δραστηριότητές του και, ως εκ τούτου, δεν είναι σε θέση να συμμορφωθεί με τις υποχρεώσεις που ορίζονται στον παρόντα κανονισμό, ενημερώνει τις αρμόδιες αρχές εποπτείας της αγοράς σχετικά με την κατάσταση αυτή, καθώς και τους χρήστες των προϊόντων με ψηφιακά στοιχεία που έχουν τεθεί σε κυκλοφορία στην αγορά, με κάθε διαθέσιμο μέσο και στο μέτρο του δυνατού.

1.1 Παραπομπές

1.2 Εντοπισμένες απαιτήσεις

1.3 Σχετικά πρότυπα

2. Εντοπισμένες απαιτήσεις

Απαιτήσεις
Πηγή	Απαίτηση

3. Σχετικά πρότυπα

Πρότυπα
Πηγή	Απαίτηση
SCF	Statutory, Regulatory & Contractual Compliance Description Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ SCF Security, Compliance & Resilience Management System (SCRMS) ∙ Governance, Risk and Compliance (GRC) solution (e.g., SCFConnect, SureCloud, Ostendio, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ SCF Security, Compliance & Resilience Management System (SCRMS) ∙ Governance, Risk and Compliance (GRC) solution (e.g., SCFConnect, SureCloud, Ostendio, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ SCF Security, Compliance & Resilience Management System (SCRMS) ∙ Governance, Risk and Compliance (GRC) solution (e.g., SCFConnect, SureCloud, Ostendio, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.) ∙ Steering committee Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ SCF Security, Compliance & Resilience Management System (SCRMS) ∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.) ∙ Steering committee Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ SCF Security, Compliance & Resilience Management System (SCRMS) ∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.) ∙ Steering committee 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 Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Compliance efforts are narrowly-limited to certain compliance requirements. ▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations. Level 2 Planned Tracked Compliance (CPL) 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 CPL domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CPL 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 CPL domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Compliance management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations. ▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements. Level 3 Well Defined Compliance (CPL) 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 CPL 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 CPL domain capabilities are well-documented and kept current by process owners. ▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform). ▪ 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 CPL 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). ▪ An implemented and operational capability exists to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls. 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	Conformity Assessment Description Mechanisms exist to conduct assessments to demonstrate security, compliance and/or resilience capability conformity with applicable cybersecurity and data protection laws, regulations and/or contractual obligations. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Document applicable regulatory requirements in a checklist Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Compliance checklist ∙ Annual compliance review Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Compliance management program ∙ Regulatory mapping ∙ Compliance calendar Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.) ∙ Compliance team Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.) ∙ Dedicated compliance team ∙ Automated compliance monitoring 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 Compliance (CPL) 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 CPL domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CPL 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 CPL domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Compliance management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to assigned cybersecurity and/or data protection controls to comply with specific compliance requirements. Level 3 Well Defined Compliance (CPL) 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 CPL 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 CPL domain capabilities are well-documented and kept current by process owners. ▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform). ▪ 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 CPL 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). ▪ An implemented and operational capability exists to conduct assessments to demonstrate security, compliance and/or resilience capability conformity with applicable cybersecurity and data protection laws, regulations and/or contractual obligations. 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	Security, Compliance & Resilience Status Reporting Description Mechanisms exist to submit status reporting of the organization's security, compliance and/or resilience program to applicable statutory and/or regulatory authorities, as required. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Maintain records for any required compliance filings Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Designate a compliance contact for required reporting ∙ Track reporting deadlines Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Compliance calendar for required submissions ∙ Documented reporting procedures Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Compliance tracking platform ∙ Dedicated compliance officer ∙ Standardized reporting templates Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise GRC platform for compliance reporting ∙ Dedicated compliance team ∙ Automated regulatory submission tracking ∙ Legal and compliance integration 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 SCR-CMM Level 2 criteria definitions are not available for this control: ▪ A reasonable person would conclude a well-defined and standardized process is required. ▪ At this level of maturity, the “requirements-driven” nature of performing the control is focused on a localized and/or regionalized implementation, not uniform and consistent across the organization. ▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts). Level 3 Well Defined Compliance (CPL) 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 CPL 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 CPL domain capabilities are well-documented and kept current by process owners. ▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform). ▪ 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 CPL 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). ▪ An implemented and operational capability exists to submit status reporting of the organization's security, compliance and/or resilience program to applicable statutory and/or regulatory authorities, as required. 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	Media & Data Retention Description Mechanisms exist to retain media and data in accordance with applicable statutory, regulatory and contractual obligations. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Data retention program ∙ Data classification program Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Data retention program ∙ Data classification program Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Data retention program ∙ Data classification program Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Data retention program ∙ Data classification program ∙ Data governance program Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Data retention program ∙ Data classification program ∙ Data governance program 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 Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media. ▪ A manual data retention process exists. ▪ Media is securely stored until it is destroyed or sanitized using approved equipment, techniques and procedures. Level 2 Planned Tracked Data Classification & Handling (DCH) 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 DCH domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with DCH 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 DCH domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Data classification and handling management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations. ▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to dispose of, destroy, erase, and/or anonymize sensitive/regulated data. Level 3 Well Defined Data Classification & Handling (DCH) 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 DCH 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 DCH domain capabilities are well-documented and kept current by process owners. ▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform). ▪ 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 DCH 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). ▪ An implemented and operational capability exists to retain media and data in accordance with applicable statutory, regulatory and contractual obligations. Level 4 Quantitatively Controlled Data Classification & Handling (DCH) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. 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	Applied Security, Compliance and Resilience Controls Documentation Description Mechanisms exist to generate authoritative documentation (e.g., System Security Plan (SSP)) that: (1) Identifies key architectural and implementation information on in-scope Technology Assets, Applications and/or Services (TAAS); (2) Reflects the current state of applied security, compliance and resilience controls on applicable People, Processes, Technologies, Data and/or Facilities (PPTDF) that are contained within the system boundary; and (3) Provides a historical record of applied security controls, including changes. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ System Security Plan (SSP) ∙ System Security & Privacy Plan (SSPP) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ System Security Plan (SSP) ∙ System Security & Privacy Plan (SSPP) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ System Security Plan (SSP) ∙ System Security & Privacy Plan (SSPP) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ System Security Plan (SSP) ∙ System Security & Privacy Plan (SSPP) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ System Security Plan (SSP) ∙ System Security & Privacy Plan (SSPP) 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 Information Assurance (IAO) 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 IAO domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with IAO 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 IAO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Information Assurance (IA)-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ IA management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Pre-production security testing is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ IT and/or cybersecurity personnel implement and maintain a limited Information Assurance Program (IAP) capability to conduct limited control testing to meet specific statutory, regulatory and/or contractual requirements for pre-production cybersecurity and data protection control testing. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to develop and maintain System Security Plans (SSPs) or similar documentation, to identify and maintain key architectural information for each business-critical Technology Assets, Applications and/or Services (TAAS). Level 3 Well Defined Information Assurance (IAO) 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 IAO 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 IAO domain capabilities are well-documented and kept current by process owners. ▪ An information assurance team, or similar function, is appropriately staffed and supported to implement and maintain IAO domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of information assurance operations (e.g., assessment scheduling software and risk assessment software). ▪ 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 IAO 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). ▪ An implemented and operational capability exists to generate authoritative documentation (e.g., System Security Plan (SSP)) that: (1) Identifies key architectural and implementation information on in-scope Technology Assets, Applications and/or Services (TAAS); (2) Reflects the current state of applied security, compliance and resilience controls on applicable People, Processes, Technologies, Data and/or Facilities (PPTDF) that are contained within the system boundary; and (3) Provides a historical record of applied security controls, including changes. Level 4 Quantitatively Controlled Information Assurance (IAO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. 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	Product Management Description Mechanisms exist to design and implement product management processes to proactively govern the design, development and production of Technology Assets, Applications and/or Services (TAAS) across the System Development Life Cycle (SDLC) to: (1) Improve functionality; (2) Enhance security and resiliency capabilities; (3) Correct security deficiencies; and (4) Conform with applicable statutory, regulatory and/or contractual obligations. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements ∙ System Development Lifecycle (SDLC) governance / oversight Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements ∙ System Development Lifecycle (SDLC) governance / oversight Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements ∙ System Development Lifecycle (SDLC) governance / oversight 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 Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Technology development & acquisition-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ IT and/or cybersecurity personnel use an informal process to govern changes to the software library to prevent unauthorized changes and create an audit trail of changes made. Level 2 Planned Tracked Technology Development & Acquisition (TDA) 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 TDA domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TDA 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 TDA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Technology development and acquisition management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure development practices mostly conform to industry-recognized standards for secure engineering of Technology Assets, Applications and/or Services (TAAS) (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ An application development team, or similar function, uses a structured process to design, build and maintain secure configurations for test, development, staging and production environments. ▪ Development and acquisition management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. Level 3 Well Defined Technology Development & Acquisition (TDA) 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 TDA 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 TDA domain capabilities are well-documented and kept current by process owners. ▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution and software testing tools). ▪ 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 TDA 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). ▪ An implemented and operational capability exists to design and implement product management processes to proactively govern the design, development and production of Technology Assets, Applications and/or Services (TAAS) across the System Development Life Cycle (SDLC) to: (1) Improve functionality; (2) Enhance security and resiliency capabilities; (3) Correct security deficiencies; and (4) Conform with applicable statutory, regulatory and/or contractual obligations. Level 4 Quantitatively Controlled Technology Development & Acquisition (TDA) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. 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.

Builddate: 20.11.2024 00:00:00 -Doknr: CELEX:32024R2847
EULAW -
European Regulation published on http://eur-lex.europa.eu/