+Articolo 13 Obblighi dei fabbricanti
---+Articolo 13 1.
---+Articolo 13 2.
---+Articolo 13 3.
---+Articolo 13 4.
---+Articolo 13 5.
---+Articolo 13 6.
---+Articolo 13 7.
---+Articolo 13 8.
---+Articolo 13 9.
---+Articolo 13 10.
---+Articolo 13 11.
---+Articolo 13 12.
---+Articolo 13 13.
---+Articolo 13 14.
---+Articolo 13 15.
---+Articolo 13 16.
---+Articolo 13 17.
---+Articolo 13 18.
---+Articolo 13 19.
---+Articolo 13 20.
---+Articolo 13 21.
---+Articolo 13 22.
---+Articolo 13 23.
---+Articolo 13 24.
---+Articolo 13 25.
|
Articolo 13 Obblighi dei fabbricanti
-
1. Panoramica
| Titolo |
Regolamentazione |
|
Articolo 13 1.
|
All’atto dell’immissione sul mercato di un prodotto con elementi digitali, i fabbricanti assicurano che esso sia stato progettato, sviluppato e prodotto conformemente ai requisiti essenziali di cibersicurezza di cui all’allegato I, parte I.
|
|
Articolo 13 2.
|
Ai fini della conformità al paragrafo 1, i fabbricanti effettuano una valutazione dei rischi di cibersicurezza associati a un prodotto con elementi digitali e tengono conto dei risultati di tale valutazione durante le fasi di pianificazione, progettazione, sviluppo, produzione, consegna e manutenzione del prodotto con elementi digitali, allo scopo di ridurre al minimo i rischi di cibersicurezza, prevenire gli incidenti e ridurne al minimo il loro impatto, anche in relazione alla salute e alla sicurezza degli utilizzatori.
|
|
Articolo 13 3.
|
La valutazione dei rischi di cibersicurezza è documentata e aggiornata, se del caso, durante un periodo di assistenza da determinare conformemente al paragrafo 8 del presente articolo. Tale valutazione comprende almeno un’analisi dei rischi di cibersicurezza basata sulla finalità prevista e sull’uso ragionevolmente prevedibile del prodotto con elementi digitali, nonché sulle sue condizioni d’uso, quali l’ambiente operativo o gli attivi da proteggere, tenendo conto della durata di utilizzo del prodotto prevista. La valutazione dei rischi di cibersicurezza indica se, ed eventualmente in che modo, i requisiti di sicurezza di cui all’allegato I, parte I, punto 2, sono applicabili al pertinente prodotto con elementi digitali e le modalità di attuazione di tali requisiti sulla base della valutazione dei rischi di cibersicurezza. Indica inoltre le modalità con cui il fabbricante intende applicare l’allegato I, parte I, punto 1, e i requisiti di gestione delle vulnerabilità di cui all’allegato I, parte II.
|
|
Articolo 13 4.
|
All’atto dell’immissione sul mercato di un prodotto con elementi digitali, il fabbricante include la valutazione dei rischi di cibersicurezza di cui al paragrafo 3 del presente articolo nella documentazione tecnica richiesta a norma dell’articolo 31 e dell’allegato VII. Per i prodotti con elementi digitali di cui all’articolo 12, che sono soggetti anche ad altri atti giuridici dell’Unione, la valutazione dei rischi di cibersicurezza può far parte della valutazione dei rischi prevista da tali atti giuridici dell’Unione. Se alcuni requisiti essenziali di cibersicurezza non sono applicabili al prodotto con elementi digitali, il fabbricante fornisce una chiara giustificazione in tal senso nella suddetta documentazione tecnica.
|
|
Articolo 13 5.
|
Ai fini dell’adempimento dell’obbligo di cui al paragrafo 1, i fabbricanti esercitano la dovuta diligenza quando integrano componenti provenienti da terzi affinché tali componenti non compromettano la cibersicurezza del prodotto con elementi digitali, anche quando integrano componenti di software liberi e open source che non sono stati messi a disposizione sul mercato nel corso di un’attività commerciale.
|
|
Articolo 13 6.
|
Quando è individuata una vulnerabilità in un componente, compreso un componente open source, integrato nel prodotto con elementi digitali, i fabbricanti la segnalano alla persona o al soggetto che si occupa della fabbricazione o della manutenzione del componente e affrontano e correggono la vulnerabilità conformemente ai requisiti di gestione delle vulnerabilità di cui all’allegato I, parte II. Qualora abbiano sviluppato una modifica del software o dell’hardware per affrontare la vulnerabilità di tale componente, i fabbricanti condividono il codice o la documentazione pertinenti con la persona o il soggetto che si occupa della fabbricazione o della manutenzione del componente, se del caso in un formato leggibile da un dispositivo automatico.
|
|
Articolo 13 7.
|
I fabbricanti documentano sistematicamente, in modo proporzionato alla natura e ai rischi di cibersicurezza, gli aspetti pertinenti di cibersicurezza relativi al prodotto con elementi digitali, comprese le vulnerabilità di cui vengono a conoscenza e qualsiasi informazione pertinente fornita da terzi e, se del caso, aggiornano la valutazione dei rischi di cibersicurezza del prodotto.
|
|
Articolo 13 8.
|
All’atto dell’immissione sul mercato di un prodotto con elementi digitali e per la durata del periodo di assistenza, i fabbricanti garantiscono che le vulnerabilità di tale prodotto, compresi i suoi componenti, siano gestite in modo efficace e in conformità dei requisiti essenziali di cibersicurezza di cui all’allegato I, parte II. I fabbricanti determinano il periodo di assistenza in modo che rifletta la durata di utilizzo prevista del prodotto, tenendo conto, in particolare, delle ragionevoli aspettative degli utilizzatori, della natura del prodotto, compresa la sua finalità prevista, nonché del pertinente diritto dell’Unione che determina la durata di vita dei prodotti con elementi digitali. Nel determinare il periodo di assistenza, i fabbricanti possono tenere conto anche dei periodi di assistenza dei prodotti con elementi digitali che offrono funzionalità analoghe immessi sul mercato da altri fabbricanti, della disponibilità dell’ambiente operativo, dei periodi di assistenza dei componenti integrati che forniscono funzioni essenziali e che provengono da terzi, nonché degli orientamenti pertinenti forniti dall’apposito gruppo di cooperazione amministrativa (ADCO) istituito a norma dell’articolo 52, paragrafo 15, e dalla Commissione. Le questioni da prendere in considerazione per determinare il periodo di assistenza sono prese in considerazione in modo da garantire la proporzionalità. Fatto salvo il secondo comma, il periodo di assistenza è di almeno cinque anni. Se si prevede che il prodotto con elementi digitali sarà utilizzato per meno di cinque anni, il periodo di assistenza corrisponde alla durata di utilizzo prevista. Tenendo conto delle raccomandazioni dell’ADCO di cui all’articolo 52, paragrafo 16, la Commissione può adottare atti delegati conformemente all’articolo 61 al fine di integrare il presente regolamento specificando il periodo minimo di assistenza per determinate categorie di prodotti qualora i dati di vigilanza del mercato suggeriscano l’inadeguatezza dei periodi di assistenza. I fabbricanti includono nella documentazione tecnica di cui all’allegato VII le informazioni prese in considerazione per determinare il periodo di assistenza di un prodotto con elementi digitali. I fabbricanti dispongono di politiche e procedure adeguate, comprese politiche di divulgazione coordinata delle vulnerabilità, di cui all’allegato I, parte II, punto 5, per trattare e correggere potenziali vulnerabilità del prodotto con elementi digitali segnalate da fonti interne o esterne.
|
|
Articolo 13 9.
|
I fabbricanti garantiscono che ciascun aggiornamento di sicurezza di cui all’allegato I, parte II, punto 8, che è stato messo a disposizione degli utilizzatori durante il periodo di assistenza, rimanga disponibile dopo il rilascio per un minimo di dieci anni o per il restante periodo di assistenza, se quest’ultimo è superiore.
|
|
Articolo 13 10.
|
Il fabbricante che abbia immesso sul mercato versioni successive sostanzialmente modificate di un software può garantire la conformità al requisito essenziale di cibersicurezza di cui all’allegato I, parte II, punto 2, solo per l’ultima versione immessa sul mercato, a condizione che gli utilizzatori delle versioni precedentemente immesse sul mercato abbiano accesso gratuito all’ultima versione immessa sul mercato e non debbano sostenere costi aggiuntivi per adeguare l’ambiente hardware e software in cui utilizzano la versione originale del prodotto.
|
|
Articolo 13 11.
|
I fabbricanti possono tenere archivi pubblici di software per migliorare l’accesso degli utilizzatori alle versioni precedenti. In questi casi, gli utilizzatori sono informati in modo chiaro e facilmente accessibile dei rischi associati all’uso di software privi di assistenza.
|
|
Articolo 13 12.
|
Prima di immettere un prodotto con elementi digitali sul mercato, i fabbricanti redigono la documentazione tecnica di cui all’articolo 31. Essi seguono o fanno eseguire le procedure di valutazione della conformità prescelte di cui all’articolo 32. Se tale procedura di valutazione della conformità dimostra la conformità del prodotto con elementi digitali ai requisiti essenziali di cibersicurezza di cui all’allegato I, parte I, e dei processi messi in atto dal fabbricante ai requisiti essenziali di cibersicurezza di cui all’allegato I, parte II, i fabbricanti redigono la dichiarazione di conformità UE conformemente all’articolo 28 e appongono la marcatura CE conformemente all’articolo 30.
|
|
Articolo 13 13.
|
I fabbricanti tengono la documentazione tecnica e la dichiarazione di conformità UE a disposizione delle autorità di vigilanza del mercato per un periodo di almeno dieci anni dalla data di immissione sul mercato del prodotto con elementi digitali o per il periodo di assistenza, se quest’ultimo è superiore.
|
|
Articolo 13 14.
|
I fabbricanti si assicurano che siano predisposte le procedure necessarie affinché i prodotti con elementi digitali fabbricati nell’ambito di una produzione in serie rimangano conformi al presente regolamento. I fabbricanti tengono adeguatamente conto delle modifiche del processo di sviluppo e di produzione o della progettazione o delle caratteristiche del prodotto con elementi digitali, nonché delle modifiche delle norme armonizzate, dei sistemi europei di certificazione della cibersicurezza o delle specifiche comuni di cui all’articolo 27 con riferimento alle quali è dichiarata la conformità del prodotto con elementi digitali o mediante applicazione delle quali tale conformità è verificata.
|
|
Articolo 13 15.
|
I fabbricanti garantiscono che i loro prodotti con elementi digitali rechino un numero di tipo, di lotto o di serie o qualsiasi altro elemento che ne consenta l’identificazione, oppure, qualora ciò non sia possibile, che tali informazioni siano fornite sull’imballaggio o in un documento di accompagnamento del prodotto con elementi digitali.
|
|
Articolo 13 16.
|
I fabbricanti indicano il loro nome, la loro denominazione commerciale registrata o il loro marchio registrato, l’indirizzo postale, l’indirizzo di posta elettronica o altri dati di contatto digitale nonché, se disponibile, il sito web presso cui possono essere contattati, sul prodotto con elementi digitali, sull’imballaggio o in un documento di accompagnamento del prodotto con elementi digitali. Tali informazioni sono incluse anche nelle informazioni e nelle istruzioni per l’utilizzatore di cui all’allegato II. I dati di recapito sono redatti in una lingua facilmente comprensibile dagli utilizzatori e dalle autorità di vigilanza del mercato.
|
|
Articolo 13 17.
|
Ai fini del presente regolamento, i fabbricanti designano un punto di contatto unico che consenta agli utilizzatori di comunicare direttamente e rapidamente con loro, anche per facilitare la segnalazione di vulnerabilità del prodotto con elementi digitali. I fabbricanti garantiscono che il punto di contatto unico sia facilmente identificabile dagli utilizzatori. Essi includono inoltre il punto di contatto unico nelle informazioni e istruzioni per l’utilizzatore di cui all’allegato II. Il punto di contatto unico consente agli utilizzatori di scegliere i mezzi di comunicazione preferiti, senza limitarli agli strumenti automatizzati.
|
|
Articolo 13 18.
|
I fabbricanti provvedono affinché i prodotti con elementi digitali siano accompagnati dalle informazioni e dalle istruzioni per l’utilizzatore di cui all’allegato II in forma cartacea o elettronica. Tali informazioni e istruzioni sono fornite in una lingua facilmente comprensibile dagli utilizzatori e dalle autorità di vigilanza del mercato. Sono chiare, comprensibili, intelligibili e leggibili. Consentono un’installazione, un funzionamento e un utilizzo sicuri dei prodotti con elementi digitali. I fabbricanti mantengono a disposizione degli utilizzatori e delle autorità di vigilanza del mercato le informazioni e istruzioni per l’utilizzatore di cui all’allegato II per un periodo di almeno dieci anni dalla data in cui il prodotto con elementi digitali è stato immesso sul mercato o per il periodo di assistenza, se quest’ultimo è superiore. Qualora tali informazioni e istruzioni siano fornite online, i fabbricanti garantiscono che siano accessibili, di facile uso e disponibili online per un periodo di almeno dieci anni dalla data in cui il prodotto con elementi digitali è stato immesso sul mercato o per il periodo di assistenza, se quest’ultimo è superiore.
|
|
Articolo 13 19.
|
I fabbricanti garantiscono che la data finale del periodo di assistenza di cui al paragrafo 8, comprendente almeno il mese e l’anno, sia specificata in modo chiaro e comprensibile al momento dell’acquisto in modo facilmente accessibile e, se del caso, sul prodotto con elementi digitali, sul suo imballaggio o con mezzi digitali. Ove tecnicamente fattibile alla luce della natura del prodotto con elementi digitali, i fabbricanti inviano una notifica agli utilizzatori per informarli che il loro prodotto con elementi digitali ha raggiunto la fine del periodo di assistenza.
|
|
Articolo 13 20.
|
I fabbricanti forniscono una copia della dichiarazione di conformità UE o una dichiarazione di conformità UE semplificata con il prodotto con elementi digitali. Se è fornita una dichiarazione di conformità UE semplificata, questa contiene l’esatto indirizzo Internet dove è possibile accedere alla dichiarazione di conformità UE completa.
|
|
Articolo 13 21.
|
A partire dall’immissione sul mercato e per la durata del periodo di assistenza, i fabbricanti che hanno la certezza o motivo di credere che il prodotto con elementi digitali o i processi messi in atto dal fabbricante non siano conformi ai requisiti essenziali di cibersicurezza di cui all’allegato I adottano immediatamente le misure correttive necessarie per rendere conformi il prodotto con elementi digitali o i processi del fabbricante oppure, a seconda dei casi, per ritirare o richiamare il prodotto.
|
|
Articolo 13 22.
|
I fabbricanti, su richiesta motivata di un’autorità di vigilanza del mercato, forniscono a tale autorità, in una lingua che può essere facilmente compresa da quest’ultima, tutte le informazioni e la documentazione, in formato cartaceo o elettronico, necessarie a dimostrare la conformità del prodotto con elementi digitali e dei processi messi in atto dal fabbricante ai requisiti essenziali di cibersicurezza di cui all’allegato I. I fabbricanti cooperano con tale autorità, su richiesta di quest’ultima, in merito a qualsiasi misura adottata per eliminare i rischi di cibersicurezza presentati dal prodotto con elementi digitali che hanno immesso sul mercato.
|
|
Articolo 13 23.
|
Il fabbricante che cessa l’attività e di conseguenza non è in grado di conformarsi al presente regolamento informa, prima che la cessazione dell’attività abbia effetto, le autorità di vigilanza del mercato competenti, nonché, con ogni mezzo disponibile e nella misura del possibile, gli utilizzatori dei prodotti pertinenti con elementi digitali interessati immessi sul mercato, dell’imminente cessazione dell’attività.
|
|
Articolo 13 24.
|
La Commissione può, mediante atti di esecuzione che tengano conto delle norme e delle migliori pratiche europee o internazionali, specificare il formato e gli elementi della distinta base del software di cui all’allegato I, parte II, punto 1. Tali atti di esecuzione sono adottati secondo la procedura d’esame di cui all’articolo 62, paragrafo 2.
|
|
Articolo 13 25.
|
Al fine di valutare la dipendenza degli Stati membri e dell’Unione nel suo complesso dai componenti software e, in particolare, dai componenti che si qualificano come software liberi e open source, l’ADCO può decidere di condurre una valutazione della dipendenza a livello dell’Unione per determinate categorie di prodotti con elementi digitali. A tal fine, le autorità di vigilanza del mercato possono chiedere ai fabbricanti di tali categorie di prodotti con elementi digitali di fornire le distinte base del software pertinenti di cui all’allegato I, parte II, punto 1. Sulla base di tali informazioni, le autorità di vigilanza del mercato possono fornire all’ADCO informazioni anonimizzate e aggregate sulle dipendenze in materia di software. L’ADCO presenta una relazione sui risultati della valutazione delle dipendenze al gruppo di cooperazione istituito a norma dell’articolo 14 della direttiva (UE) 2022/2555.
|
,
1.1 Riferimenti
1.2 Requisiti identificati
1.3 Standard correlati
2. Requisiti identificati
Requisiti
| Fonte |
Requisito |
3. Standard correlati
Standard
| Fonte |
Requisito |
|
SCF
|
Ability To Demonstrate Conformity
Description
Mechanisms exist to ensure the organization is able 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.
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 ensure the organization is able 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
Compliance (CPL) 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
|
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
|
Grievances
Description
Mechanisms exist to govern the intake and analysis of grievances related to the organization's cybersecurity and/or data protection practices.
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
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.
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 govern the intake and analysis of grievances related to the organization's cybersecurity and/or data protection practices.
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
|
Information Assurance (IA) Operations
Description
Mechanisms exist to facilitate the implementation of security, compliance and resilience assessment and authorization controls.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Controls Validation Testing (CVT)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Controls Validation Testing (CVT)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
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
Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Pre-production security testing-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel implement and maintain an informal process to conduct limited control testing of High Value Assets (HVAs) to meet specific statutory, regulatory and/or contractual requirements for pre-production cybersecurity and data protection control testing.
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.
▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
▪ IT and/or cybersecurity personnel coordinate IAP activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.
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 facilitate the implementation of security, compliance and resilience assessment and authorization controls.
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
|
Assessment Boundaries
Description
Mechanisms exist to establish the scope of assessments by defining the assessment boundary, according to people, processes and technology that directly or indirectly impact the confidentiality, integrity, availability and safety of the Technology Assets, Applications, Services and/or Data (TAASD) under review.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Define which systems and people are in scope for security reviews
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Documented assessment scope (systems, processes, personnel) for audits/assessments
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Assessment boundary definition (people, process, technology) in assessment plans
∙ Authorization boundary diagrams
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Formal assessment boundary methodology (e.g., FedRAMP/CMMC scoping guidance)
∙ Boundary documentation in SSP
∙ Scope approval by stakeholders
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise assessment scoping standards with documented authorization boundaries across systems
∙ GRC platform scoping and asset linkage
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
Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Pre-production security testing-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel implement and maintain an informal process to conduct limited control testing of High Value Assets (HVAs) to meet specific statutory, regulatory and/or contractual requirements for pre-production cybersecurity and data protection control testing.
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.
▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
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 establish the scope of assessments by defining the assessment boundary, according to people, processes and technology that directly or indirectly impact the confidentiality, integrity, availability and safety of the TAASD under review.
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
|
Control Validation Testing (CVT)
Description
Mechanisms exist to formally assess the security, compliance and resilience controls in Technology Assets, Applications and/or Services (TAAS) through Information Assurance Program (IAP) activities to determine the extent to which the controls are implemented correctly, operating as intended and producing the desired outcome with respect to meeting expected requirements.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Controls Validation Testing (CVT)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Controls Validation Testing (CVT)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
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
Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Pre-production security testing-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel implement and maintain an informal process to conduct limited control testing of High Value Assets (HVAs) to meet specific statutory, regulatory and/or contractual requirements for pre-production cybersecurity and data protection control testing.
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.
▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
▪ IT and/or cybersecurity personnel coordinate IAP activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.
▪ IAP testing results in a formal risk assessment where Business process owners (BPOs) are required to make a decision to (1) reduce, (2) avoid, (3) transfer and/or (4) accept risk(s) on behalf of the organization.
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 formally assess the security, compliance and resilience controls in Technology Assets, Applications and/or Services (TAAS) through Information Assurance Program (IAP) activities to determine the extent to which the controls are implemented correctly, operating as intended and producing the desired outcome with respect to meeting expected requirements.
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
|
Specialized Assessments
Description
Mechanisms exist to conduct specialized assessments for:
(1) Statutory, regulatory and contractual compliance obligations;
(2) Monitoring capabilities;
(3) Mobile devices;
(4) Databases;
(5) Application security;
(6) Embedded technologies (e.g., IoT and OT);
(7) Vulnerability management;
(8) Malicious code;
(9) Insider threats;
(10) Performance/load testing;
(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or
(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Controls Validation Testing (CVT)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Controls Validation Testing (CVT)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Controls Validation Testing (CVT)
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Controls Validation Testing (CVT)
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Controls Validation Testing (CVT)
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
Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Pre-production security testing-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel implement and maintain an informal process to conduct limited control testing of High Value Assets (HVAs) to meet specific statutory, regulatory and/or contractual requirements for pre-production cybersecurity and data protection control testing.
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.
▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
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 conduct specialized assessments for:
(1) Statutory, regulatory and contractual compliance obligations;
(2) Monitoring capabilities;
(3) Mobile devices;
(4) Databases;
(5) Application security;
(6) Embedded technologies (e.g., IoT and OT);
(7) Vulnerability management;
(8) Malicious code;
(9) Insider threats;
(10) Performance/load testing;
(11) Artificial Intelligence and Autonomous Technologies (AAT); and/or
(12) Other Technology Assets, Applications and/or Services (TAAS) that require specialized expertise to determine conformity with security, compliance and/or resilience requirements.
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
|
Assessor Independence
Description
Mechanisms exist to ensure assessors or assessment teams have the appropriate independence to conduct security, compliance and/or resilience control assessments.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Security reviews performed by someone other than the person who built/operates the system, or external assessor
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Independent internal reviewer or third-party assessor
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Assessor independence requirements in the IA program
∙ Third-party assessments for critical systems
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Independent assessment function (internal audit or third-party)
∙ Independence criteria documented
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise independent assurance function (internal audit, second line) and third-party assessors
∙ Independence standards aligned with IIA and regulatory requirements
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
Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Pre-production security testing-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel implement and maintain an informal process to conduct limited control testing of High Value Assets (HVAs) to meet specific statutory, regulatory and/or contractual requirements for pre-production cybersecurity and data protection control testing.
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.
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 ensure assessors or assessment teams have the appropriate independence to conduct security, compliance and/or resilience control assessments.
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
|
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
|
Threat Analysis & Flaw Remediation During Development
Description
Mechanisms exist to require system developers and integrators to create and execute a Security Testing and Evaluation (ST&E) plan, or similar process, to identify and remediate flaws during development.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Pre-production Control Validation Testing (CVT)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Pre-production Control Validation Testing (CVT)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Pre-production Control Validation Testing (CVT)
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Pre-production Control Validation Testing (CVT)
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Pre-production Control Validation Testing (CVT)
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.
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 require system developers and integrators to create and execute a Security Testing and Evaluation (ST&E) plan, or similar process, to identify and remediate flaws during development.
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
|
Technical Verification
Description
Mechanisms exist to perform Control Validation Testing (CVT) activities to evaluate the design, implementation and effectiveness of technical security, compliance and resilience controls.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Controls Validation Testing (CVT)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Controls Validation Testing (CVT)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Controls Validation Testing (CVT)
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Controls Validation Testing (CVT)
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Controls Validation Testing (CVT)
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.
▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
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 perform Information Assurance Program (IAP) activities to evaluate the design, implementation and effectiveness of technical security, compliance and resilience controls.
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
|
Capabilities Deficiency Tracking
Description
Mechanisms exist to govern identified deficiencies (e.g., Plan of Action and Milestones (POA&M) or similar methodology) that formally documents, at a minimum:
(1) Deficiency tracking number;
(2) Applicable security, compliance and/or resilience control;
(3) Description of the deficiency(ies);
(4) Risk associated with the deficiency(ies);
(5) Source deficiency identification/detection;
(6) Temporary compensating controls, if applicable;
(7) Point of Contact (POC) (e.g., asset/process owner);
(8) Resources required to conduct remediation actions;
(9) Planned remedial actions to the deficiency(ies);
(10) Proposed remediation timeline; and
(11) Disposition statement (e.g., closeout summary).
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Plan of Action and Milestones (POA&M)
∙ Risk register
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Plan of Action and Milestones (POA&M)
∙ Risk register
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Plan of Action and Milestones (POA&M)
∙ Risk register
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Plan of Action and Milestones (POA&M)
∙ Risk register
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Plan of Action and Milestones (POA&M)
∙ Risk register
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.
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 govern identified deficiencies (e.g., Plan of Action and Milestones (POA&M) or similar methodology) that formally documents, at a minimum:
(1) Deficiency tracking number;
(2) Applicable security, compliance and/or resilience control;
(3) Description of the deficiency(ies);
(4) Risk associated with the deficiency(ies);
(5) Source deficiency identification/detection;
(6) Temporary compensating controls, if applicable;
(7) Point of Contact (POC) (e.g., asset/process owner);
(8) Resources required to conduct remediation actions;
(9) Planned remedial actions to the deficiency(ies);
(10) Proposed remediation timeline; and
(11) Disposition statement (e.g., closeout summary).
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
|
Security Assessment Report (SAR)
Description
Mechanisms exist to produce a Security Assessment Report (SAR) at the conclusion of a security assessment to certify the results of the assessment and assist with any remediation actions.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Controls Validation Testing (CVT)
∙ Security Assessment Report (SAR)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Controls Validation Testing (CVT)
∙ Security Assessment Report (SAR)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Controls Validation Testing (CVT)
∙ Security Assessment Report (SAR)
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Controls Validation Testing (CVT)
∙ Security Assessment Report (SAR)
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Controls Validation Testing (CVT)
∙ Security Assessment Report (SAR)
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.
▪ IAP testing results in a formal risk assessment where Business process owners (BPOs) are required to make a decision to (1) reduce, (2) avoid, (3) transfer and/or (4) accept risk(s) on behalf of the organization.
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 produce a Security Assessment Report (SAR) at the conclusion of a security assessment to certify the results of the assessment and assist with any remediation actions.
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 Authorization
Description
Mechanisms exist to ensure Technology Assets, Applications and/or Services (TAAS) are officially authorized prior to "go live" in a production environment.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Owner approval before new systems go live
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Go-live approval checklist including security review
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Formal authorization to operate before production (Authorizing Official sign-off)
∙ Security Assessment Report (SAR) input
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Security authorization process (e.g., RMF-based) with documented authorization decisions
∙ Authorization tracked in GRC
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise security authorization program (RMF/ATO) with continuous authorization
∙ GRC platform authorization workflows
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
Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Pre-production security testing-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel implement and maintain an informal process to conduct limited control testing of High Value Assets (HVAs) to meet specific statutory, regulatory and/or contractual requirements for pre-production cybersecurity and data protection control testing.
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.
▪ IAP testing results in a formal risk assessment where Business process owners (BPOs) are required to make a decision to (1) reduce, (2) avoid, (3) transfer and/or (4) accept risk(s) on behalf of the organization.
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 ensure Technology Assets, Applications and/or Services (TAAS) are officially authorized prior to "go live" in a production environment.
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
|
Information Assurance (IA) Operations
Description
Mechanisms exist to facilitate the implementation of security, compliance and resilience assessment and authorization controls.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Controls Validation Testing (CVT)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Controls Validation Testing (CVT)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
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
Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Pre-production security testing-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel implement and maintain an informal process to conduct limited control testing of High Value Assets (HVAs) to meet specific statutory, regulatory and/or contractual requirements for pre-production cybersecurity and data protection control testing.
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.
▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
▪ IT and/or cybersecurity personnel coordinate IAP activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.
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 facilitate the implementation of security, compliance and resilience assessment and authorization controls.
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
|
Assessment Boundaries
Description
Mechanisms exist to establish the scope of assessments by defining the assessment boundary, according to people, processes and technology that directly or indirectly impact the confidentiality, integrity, availability and safety of the Technology Assets, Applications, Services and/or Data (TAASD) under review.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Define which systems and people are in scope for security reviews
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Documented assessment scope (systems, processes, personnel) for audits/assessments
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Assessment boundary definition (people, process, technology) in assessment plans
∙ Authorization boundary diagrams
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Formal assessment boundary methodology (e.g., FedRAMP/CMMC scoping guidance)
∙ Boundary documentation in SSP
∙ Scope approval by stakeholders
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise assessment scoping standards with documented authorization boundaries across systems
∙ GRC platform scoping and asset linkage
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
Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Pre-production security testing-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel implement and maintain an informal process to conduct limited control testing of High Value Assets (HVAs) to meet specific statutory, regulatory and/or contractual requirements for pre-production cybersecurity and data protection control testing.
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.
▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
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 establish the scope of assessments by defining the assessment boundary, according to people, processes and technology that directly or indirectly impact the confidentiality, integrity, availability and safety of the TAASD under review.
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
|
Control Validation Testing (CVT)
Description
Mechanisms exist to formally assess the security, compliance and resilience controls in Technology Assets, Applications and/or Services (TAAS) through Information Assurance Program (IAP) activities to determine the extent to which the controls are implemented correctly, operating as intended and producing the desired outcome with respect to meeting expected requirements.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Controls Validation Testing (CVT)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Controls Validation Testing (CVT)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Controls Validation Testing (CVT)
∙ Information Assurance (IA) program
∙ VisibleOps security management
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
Information Assurance (IAO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IAO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Pre-production security testing-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel implement and maintain an informal process to conduct limited control testing of High Value Assets (HVAs) to meet specific statutory, regulatory and/or contractual requirements for pre-production cybersecurity and data protection control testing.
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.
▪ IAP operations focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
▪ IT and/or cybersecurity personnel coordinate IAP activities with affected stakeholders before conducting such activities in order to reduce the potential impact on operations.
▪ IAP testing results in a formal risk assessment where Business process owners (BPOs) are required to make a decision to (1) reduce, (2) avoid, (3) transfer and/or (4) accept risk(s) on behalf of the organization.
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 formally assess the security, compliance and resilience controls in Technology Assets, Applications and/or Services (TAAS) through Information Assurance Program (IAP) activities to determine the extent to which the controls are implemented correctly, operating as intended and producing the desired outcome with respect to meeting expected requirements.
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
|
Secure Development Life Cycle (SDLC) Management
Description
Mechanisms exist to ensure changes to Technology Assets, Applications and/or Services (TAAS) within the Secure Development Life Cycle (SDLC) are controlled through formal change control procedures.
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
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
Project & Resource Management (PRM) 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 PRM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with PRM 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 PRM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Project & Resource Management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ The Chief Information Officer (CIO), or similar function, analyzes the organization's business strategy and prioritizes the objectives and resourcing of the security function, based on broader business requirements.
▪ A Project Management Office (PMO), or project management function, enables the implementation of cybersecurity and data protection-related resource planning controls across the System Development Lifecycle (SDLC) for all high-value projects.
▪ The PM function enables project involvement for Information Assurance Program (IAP) as part of the organization's established project management processes to ensure both cybersecurity and data protection principles are identified and implemented.
Level 3 Well Defined
Project & Resource Management (PRM) 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 PRM 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 PRM domain capabilities are well-documented and kept current by process owners.
▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with PRM 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).
▪ The Chief Information Officer (CIO), or similar function, analyzes the organization's business strategy and prioritizes the objectives and resourcing of the security function, based on broader business requirements.
▪ An implemented and operational capability exists to ensure changes to Technology Assets, Applications and/or Services (TAAS) within the Secure Development Life Cycle (SDLC) are controlled through formal change control procedures.
Level 4 Quantitatively Controlled
Project & Resource Management (PRM) 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
|
Security, Compliance & Resilience In Project Management
Description
Mechanisms exist to assess security, compliance and resilience controls as part of Technology Assets, Applications and/or Services (TAAS) project development to determine whether controls are implemented correctly, operating as intended and producing the desired outcome with respect to meeting requirements.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Product / project management
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Product / project management
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Product / project management
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Product / project management
∙ Program Management Office (PMO)
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Product / project management
∙ Program Management Office (PMO)
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
Project & Resource Management (PRM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with PRM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Project management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel work with data/process owners to help ensure secure practices are implemented throughout the System Development Lifecycle (SDLC) for all high-value projects.
Level 2 Planned Tracked
Project & Resource Management (PRM) 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 PRM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with PRM 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 PRM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Project & Resource Management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ The Chief Information Officer (CIO), or similar function, analyzes the organization's business strategy and prioritizes the objectives and resourcing of the security function, based on broader business requirements.
▪ A Project Management Office (PMO), or project management function, enables the implementation of cybersecurity and data protection-related resource planning controls across the System Development Lifecycle (SDLC) for all high-value projects.
▪ The PM function enables project involvement for Information Assurance Program (IAP) as part of the organization's established project management processes to ensure both cybersecurity and data protection principles are identified and implemented.
Level 3 Well Defined
Project & Resource Management (PRM) 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 PRM 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 PRM domain capabilities are well-documented and kept current by process owners.
▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project management solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with PRM 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).
▪ The Chief Information Officer (CIO), or similar function, analyzes the organization's business strategy and prioritizes the objectives and resourcing of the security function, based on broader business requirements.
▪ An implemented and operational capability exists to assess security, compliance and resilience controls in system project development to determine the extent to which the controls are implemented correctly, operating as intended and producing the desired outcome with respect to meeting the requirements.
Level 4 Quantitatively Controlled
Project & Resource Management (PRM) 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.
|
|
SCF
|
Ongoing Product Security Support
Description
Mechanisms exist to deliver security updates to Technology Assets, Applications and/or Services (TAAS), where applicable, through:
(1) Automatic updates; and
(2) Notification of available updates to affected users.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Deliver security updates for any developed products; publish update notices
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Defined support period and update channel for developed products
∙ Security advisories to customers
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Product security update process with automatic updates where feasible
∙ Published support lifecycle
∙ Security advisory process
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Product Security Incident Response Team (PSIRT) delivering updates and advisories
∙ Automatic update mechanisms with integrity verification
∙ Defined end-of-support policy
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise PSIRT and product security update program (e.g., aligned with ISO/IEC 30111, EU CRA)
∙ Secure automatic update infrastructure
∙ Customer notification and support lifecycle management
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
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.
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 deliver security updates to Technology Assets, Applications and/or Services (TAAS), where applicable, through:
(1) Automatic updates; and
(2) Notification of available updates to affected users.
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
|
Functional Properties
Description
Mechanisms exist to require software developers to provide information describing the functional properties of the security, compliance and resilience controls to be utilized within Technology Assets, Applications and/or Services (TAAS) in sufficient detail to permit analysis and testing of the controls.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Product / project management
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Product / project management
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Product / project management
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Product / project management
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Product / project management
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
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.
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 require software developers to provide information describing the functional properties of the security, compliance and resilience controls to be utilized within Technology Assets, Applications and/or Services (TAAS) in sufficient detail to permit analysis and testing of the controls.
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.
|
|
SCF
|
Administrator Documentation
Description
Mechanisms exist to obtain, protect and distribute administrator documentation for Technology Assets, Applications and/or Services (TAAS) that describe:
(1) Secure configuration, installation and operation of the TAAS;
(2) Effective use and maintenance of security features/functions; and
(3) Known vulnerabilities regarding configuration and use of administrative (e.g., privileged) functions.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Product / project management
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Product / project management
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Product / project management
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Product / project management
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Product / project management
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).
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.
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 obtain, protect and distribute administrator documentation for Technology Assets, Applications and/or Services (TAAS) that describe:
(1) Secure configuration, installation and operation of the TAAS;
(2) Effective use and maintenance of security features/functions; and
(3) Known vulnerabilities regarding configuration and use of administrative (e.g., privileged) functions.
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.
|
|
SCF
|
Vulnerability Remediation Process
Description
Mechanisms exist to ensure that vulnerabilities are properly identified, tracked and remediated.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Patch software when updates are released
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Vulnerability remediation policy
∙ Prioritized patching schedule
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Formal vulnerability remediation process
∙ Risk-based prioritization
∙ Remediation SLAs
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Enterprise vulnerability remediation program
∙ Defined SLAs by severity
∙ Tracking and reporting
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise vulnerability management platform (e.g., Tenable.io, Qualys)
∙ Automated remediation tracking
∙ SIEM 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
Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Attack Surface Management (ASM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
Level 2 Planned Tracked
Vulnerability & Patch Management (VPM) 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 VPM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with VPM 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 VPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Vulnerability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
Level 3 Well Defined
Vulnerability & Patch Management (VPM) 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 VPM 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 VPM domain capabilities are well-documented and kept current by process owners.
▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution and vulnerability scanning solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with VPM 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 ensure that vulnerabilities are properly identified, tracked and remediated.
Level 4 Quantitatively Controlled
Vulnerability & Patch Management (VPM) 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
Vulnerability & Patch Management (VPM) 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.
▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.
▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies.
|
|