+Článek 19 Povinnosti dovozců
---+Článek 19 1.
---+Článek 19 2.
---+Článek 19 3.
---+Článek 19 4.
---+Článek 19 5.
---+Článek 19 6.
---+Článek 19 7.
---+Článek 19 8.
|
Článek 19 Povinnosti dovozců
-
1. Přehled
| Název |
Regulace |
|
Článek 19 1.
|
Dovozci uvádějí na trh pouze produkty s digitálními prvky, které splňují základní požadavky na kybernetickou bezpečnost stanovené v příloze I části I a u nichž jsou postupy zavedené výrobcem v souladu se základními požadavky na kybernetickou bezpečnost stanovenými v příloze I části II.
|
|
Článek 19 2.
|
Před uvedením produktu s digitálními prvky na trh dovozci zajistí, aby:
a)
výrobce provedl příslušné postupy posuzování shody podle článku 32,
b)
výrobce vypracoval technickou dokumentaci,
c)
produkt s digitálními prvky byl opatřen označením CE podle článku 30 a bylo k němu přiloženo EU prohlášení o shodě podle čl. 13 odst. 20 a informace a pokyny pro uživatele stanovené v příloze II v jazyce snadno srozumitelném uživatelům a orgánům dozoru nad trhem,
d)
výrobce splnil požadavky stanovené v čl. 13 odst. 15, 16 a 19.
Pro účely tohoto odstavce musí být dovozci schopni poskytnout nezbytné dokumenty prokazující splnění požadavků stanovených v tomto článku.
|
|
Článek 19 3.
|
Jestliže se dovozce domnívá nebo má důvod se domnívat, že produkt s digitálními prvky nebo postupy zavedené výrobcem nejsou ve shodě s tímto nařízením, neuvede dovozce produkt na trh, dokud u tohoto produktu nebo u postupů zavedených výrobcem nebude dosaženo shody s tímto nařízením. Pokud navíc produkt s digitálními prvky představuje významné kybernetické bezpečnostní riziko, informuje o tom dovozce výrobce a orgány dozoru nad trhem. Pokud má dovozce důvod se domnívat, že určitý produkt s digitálními prvky může představovat významné kybernetické bezpečnostní riziko s ohledem na rizikové faktory jiné než technické povahy, informuje o tom orgány dozoru nad trhem. Po obdržení takovýchto informací se orgány dozoru nad trhem řídí postupy uvedenými v čl. 54 odst. 2.
|
|
Článek 19 4.
|
Dovozci uvedou na produktu s digitálními prvky nebo na jeho obalu či v dokumentu přiloženém k tomuto produktu své jméno, zapsaný obchodní název nebo zapsanou ochrannou známku, poštovní adresu, e-mailovou adresu nebo jiné digitální kontaktní údaje, a případně internetovou stránku, na níž je lze kontaktovat. Kontaktní údaje se uvádějí v jazyce snadno srozumitelném uživatelům a orgánům dozoru nad trhem.
|
|
Článek 19 5.
|
Dovozci, kteří vědí nebo mají důvod se domnívat, že produkt s digitálními prvky, který uvedli na trh, není v souladu s tímto nařízením, přijmou okamžitě nápravná opatření nezbytná k zajištění toho, aby byl produkt s digitálními prvky uveden do souladu s tímto nařízením, nebo aby byl v případě potřeby stažen z trhu či z oběhu. Poté, co se dovozci dozvědí o zranitelnosti produktu s digitálními prvky, informují o této zranitelnosti bez zbytečného odkladu výrobce. Dále, pokud produkt s digitálními prvky představuje významné kybernetické bezpečnostní riziko, informují o tom dovozci neprodleně orgány dozoru nad trhem v členských státech, v nichž produkt s digitálními prvky dodali na trh, a uvedou podrobnosti, zejména o nesouladu a o přijatých nápravných opatřeních.
|
|
Článek 19 6.
|
Dovozci po dobu alespoň deseti let od uvedení produktu s digitálními prvky na trh nebo po dobu trvání doby podpory, podle toho, které z těchto časových období je delší, uchovávají kopii EU prohlášení o shodě pro potřebu orgánů dozoru nad trhem a zajišťují, aby těmto orgánům mohla být na žádost předložena technická dokumentace.
|
|
Článek 19 7.
|
Dovozci poskytnou orgánu dozoru nad trhem na základě jeho odůvodněné žádosti všechny informace a dokumentaci v tištěné nebo elektronické podobě, které jsou nezbytné k prokázání shody produktu s digitálními prvky se základními požadavky na kybernetickou bezpečnost stanovenými v příloze I části I, jakož i shody postupů zavedených výrobcem se základními požadavky na kybernetickou bezpečnost stanovenými v příloze I části II, a to v jazyce snadno srozumitelném tomuto orgánu. Spolupracují s tímto orgánem na jeho žádost na veškerých opatřeních přijatých k odstranění kybernetických bezpečnostních rizik představovaných produktem s digitálními prvky, který uvedli na trh.
|
|
Článek 19 8.
|
Pokud se dovozce produktu s digitálními prvky dozví, že výrobce tohoto produktu ukončil svou činnost, a v důsledku toho není schopen splnit povinnosti stanovené v tomto nařízení, informuje o této situaci příslušné orgány dozoru nad trhem a jakýmikoli dostupnými prostředky a v co největší míře také uživatele produktů s digitálními prvky uváděných na trh.
|
,
1.1 Odkazy
1.2 Identifikované požadavky
1.3 Související standardy
2. Identifikované požadavky
Požadavky
| Zdroj |
Požadavek |
3. Související standardy
Standardy
| Zdroj |
Požadavek |
|
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.
|
|