+Άρθρο 14 Υποχρεώσεις αναφοράς για τους κατασκευαστές
---+Άρθρο 14 1.
---+Άρθρο 14 2.
---+Άρθρο 14 3.
---+Άρθρο 14 4.
---+Άρθρο 14 5.
---+Άρθρο 14 6.
---+Άρθρο 14 7.
---+Άρθρο 14 8.
---+Άρθρο 14 9.
---+Άρθρο 14 10.

Άρθρο 14 Υποχρεώσεις αναφοράς για τους κατασκευαστές

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

,
Άρθρο 14 1.
Ο κατασκευαστής κοινοποιεί κάθε ευπάθεια που αποτελεί αντικείμενο ενεργού εκμετάλλευσης και περιέχεται στο προϊόν με ψηφιακά στοιχεία, και η οποία υποπίπτει στην αντίληψή του, ταυτόχρονα στην ΟΑΠΑΥ στην οποία έχουν ανατεθεί καθήκοντα συντονισμού, σύμφωνα με την παράγραφο 7 του παρόντος άρθρου, και στον ENISA. Ο κατασκευαστής κοινοποιεί την εν λόγω ευπάθεια που αποτελεί αντικείμενο ενεργού εκμετάλλευσης μέσω της ενιαίας πλατφόρμας αναφοράς που δημιουργείται σύμφωνα με το άρθρο 16.
Άρθρο 14 2.

Για τους σκοπούς της κοινοποίησης που αναφέρεται στην παράγραφο 1, ο κατασκευαστής υποβάλλει:

α) 

κοινοποίηση έγκαιρης προειδοποίησης σχετικά με ευπάθεια που αποτελεί αντικείμενο ενεργού εκμετάλλευσης, χωρίς αδικαιολόγητη καθυστέρηση και σε κάθε περίπτωση εντός 24 ωρών από τη στιγμή που η ευπάθεια υπέπεσε στην αντίληψη του κατασκευαστή, αναφέροντας, κατά περίπτωση, τα κράτη μέλη στην επικράτεια των οποίων έχει καταστεί διαθέσιμο το προϊόν με ψηφιακά στοιχεία εξ όσων γνωρίζει ο κατασκευαστής·

β) 

εκτός εάν έχουν ήδη παρασχεθεί οι σχετικές πληροφορίες, κοινοποίηση ευπάθειας, χωρίς αδικαιολόγητη καθυστέρηση και σε κάθε περίπτωση εντός 72 ωρών από τη στιγμή που η ευπάθεια που αποτελεί αντικείμενο ενεργού εκμετάλλευσης υπέπεσε στην αντίληψη του κατασκευαστή, η οποία παρέχει γενικές πληροφορίες, εφόσον είναι διαθέσιμες, σχετικά με το οικείο προϊόν με ψηφιακά στοιχεία, τον γενικό χαρακτήρα της εκμετάλλευσης και της σχετικής ευπάθειας, καθώς και τυχόν διορθωτικά μέτρα ή μέτρα μετριασμού που έχουν ληφθεί, και διορθωτικά μέτρα ή μέτρα μετριασμού που μπορούν να λάβουν οι χρήστες, και η οποία αναφέρει επίσης, κατά περίπτωση, πόσο ευαίσθητες θεωρεί ο κατασκευαστής τις κοινοποιηθείσες πληροφορίες·

γ) 

εκτός εάν έχουν ήδη παρασχεθεί οι σχετικές πληροφορίες, τελική έκθεση, το αργότερο 14 ημέρες μετά τη λήψη διορθωτικού μέτρου ή μέτρου μετριασμού, η οποία περιλαμβάνει τουλάχιστον τα ακόλουθα:

i) 

λεπτομερή περιγραφή της ευπάθειας, συμπεριλαμβανομένων της σοβαρότητας και των επιπτώσεών της·

ii) 

εφόσον είναι διαθέσιμες, πληροφορίες σχετικά με οποιονδήποτε κακόβουλο παράγοντα που έχει εκμεταλλευτεί ή εκμεταλλεύεται την ευπάθεια·

iii) 

λεπτομέρειες σχετικά με την ενημέρωση ασφαλείας ή άλλα διορθωτικά μέτρα που έχουν διατεθεί για την αντιμετώπιση της ευπάθειας.
Άρθρο 14 3.
Ο κατασκευαστής κοινοποιεί κάθε σοβαρό περιστατικό που έχει αντίκτυπο στην ασφάλεια του προϊόντος με ψηφιακά στοιχεία και το οποίο υποπίπτει στην αντίληψή του, ταυτόχρονα στην ΟΑΠΑΥ στην οποία έχουν ανατεθεί καθήκοντα συντονισμού, σύμφωνα με την παράγραφο 7 του παρόντος άρθρου, και στον ENISA. Ο κατασκευαστής κοινοποιεί το εν λόγω περιστατικό μέσω της ενιαίας πλατφόρμας αναφοράς που δημιουργείται σύμφωνα με το άρθρο 16.
Άρθρο 14 4.

Για τους σκοπούς της κοινοποίησης που αναφέρεται στην παράγραφο 3, ο κατασκευαστής υποβάλλει:

α) 

κοινοποίηση έγκαιρης προειδοποίησης σχετικά με σοβαρό περιστατικό που έχει αντίκτυπο στην ασφάλεια του προϊόντος με ψηφιακά στοιχεία, χωρίς αδικαιολόγητη καθυστέρηση και σε κάθε περίπτωση εντός 24 ωρών από τη στιγμή που το περιστατικό υπέπεσε στην αντίληψη του κατασκευαστή, δηλώνοντας τουλάχιστον εάν υπάρχει υπόνοια ότι το περιστατικό έχει προκληθεί από παράνομες ή κακόβουλες ενέργειες, και αναφέροντας επίσης, κατά περίπτωση, τα κράτη μέλη στην επικράτεια των οποίων έχει καταστεί διαθέσιμο το προϊόν με ψηφιακά στοιχεία εξ όσων γνωρίζει ο κατασκευαστής·

β) 

εκτός εάν έχουν ήδη παρασχεθεί οι σχετικές πληροφορίες, κοινοποίηση περιστατικού, χωρίς αδικαιολόγητη καθυστέρηση και σε κάθε περίπτωση εντός 72 ωρών από τη στιγμή που το περιστατικό υπέπεσε στην αντίληψη του κατασκευαστή, η οποία παρέχει γενικές πληροφορίες, εφόσον είναι διαθέσιμες, σχετικά με τη φύση του περιστατικού, αρχική αξιολόγηση του περιστατικού, καθώς και τυχόν διορθωτικά μέτρα ή μέτρα μετριασμού που έχουν ληφθεί, και διορθωτικά μέτρα ή μέτρα μετριασμού που μπορούν να λάβουν οι χρήστες, και η οποία αναφέρει επίσης, κατά περίπτωση, πόσο ευαίσθητες θεωρεί ο κατασκευαστής τις κοινοποιηθείσες πληροφορίες·

γ) 

εκτός εάν έχουν ήδη παρασχεθεί οι σχετικές πληροφορίες, τελική έκθεση το αργότερο ένα μήνα μετά την υποβολή της κοινοποίησης περιστατικού σύμφωνα με το στοιχείο β), η οποία περιλαμβάνει τουλάχιστον τα ακόλουθα:

i) 

λεπτομερή περιγραφή του περιστατικού, μεταξύ άλλων της σοβαρότητάς του και των επιπτώσεών του·

ii) 

το είδος της απειλής ή τη βασική αιτία που ενδεχομένως προκάλεσε το περιστατικό·

iii) 

τα εφαρμοζόμενα και εν εξελίξει μέτρα μετριασμού.
Άρθρο 14 5.

Για τους σκοπούς της παραγράφου 3, περιστατικό που έχει αντίκτυπο στην ασφάλεια του προϊόντος με ψηφιακά στοιχεία θεωρείται σοβαρό όταν:

α) 

επηρεάζει αρνητικά ή είναι ικανό να επηρεάσει αρνητικά την ικανότητα ενός προϊόντος με ψηφιακά στοιχεία να προστατεύει τη διαθεσιμότητα, την αυθεντικότητα, την ακεραιότητα ή την εμπιστευτικότητα ευαίσθητων ή σημαντικών δεδομένων ή λειτουργιών· ή

β) 

έχει οδηγήσει ή είναι ικανό να οδηγήσει στην εισαγωγή ή την εκτέλεση κακόβουλου κώδικα σε προϊόν με ψηφιακά στοιχεία ή στα συστήματα δικτύου και πληροφοριών ενός χρήστη του προϊόντος με ψηφιακά στοιχεία.
Άρθρο 14 6.
Όπου είναι αναγκαίο, η ΟΑΠΑΥ στην οποία έχουν ανατεθεί καθήκοντα συντονισμού και η οποία λαμβάνει πρώτη την κοινοποίηση μπορεί να ζητήσει από τους κατασκευαστές να υποβάλουν ενδιάμεση έκθεση σχετικά με τις οικείες επικαιροποιήσεις της κατάστασης όσον αφορά την ευπάθεια που αποτελεί αντικείμενο ενεργού εκμετάλλευσης ή το σοβαρό περιστατικό που έχει αντίκτυπο στην ασφάλεια του προϊόντος με ψηφιακά στοιχεία.
Άρθρο 14 7.
Οι κοινοποιήσεις που αναφέρονται στις παραγράφους 1 και 3 του παρόντος άρθρου υποβάλλονται μέσω της ενιαίας πλατφόρμας αναφοράς που αναφέρεται στο άρθρο 16 με τη χρήση ενός από τα τελικά σημεία ηλεκτρονικής κοινοποίησης που αναφέρονται στο άρθρο 16 παράγραφος 1. Η κοινοποίηση υποβάλλεται μέσω του τελικού σημείου ηλεκτρονικής κοινοποίησης της ΟΑΠΑΥ στην οποία έχουν ανατεθεί καθήκοντα συντονισμού, του κράτους μέλους στο οποίο οι κατασκευαστές έχουν την κύρια εγκατάστασή τους στην Ένωση, και είναι ταυτόχρονα προσβάσιμη στον ENISA.

Για τους σκοπούς του παρόντος κανονισμού, ένας κατασκευαστής θεωρείται ότι έχει την κύρια εγκατάστασή του στην Ένωση στο κράτος μέλος όπου λαμβάνονται κυρίως οι αποφάσεις σχετικά με την κυβερνοασφάλεια των προϊόντων του με ψηφιακά στοιχεία. Εάν το εν λόγω κράτος μέλος δεν μπορεί να προσδιοριστεί, η κύρια εγκατάσταση θεωρείται ότι βρίσκεται στο κράτος μέλος στο οποίο ο οικείος κατασκευαστής έχει την εγκατάσταση με τον μεγαλύτερο αριθμό εργαζομένων στην Ένωση.

Όταν ένας κατασκευαστής δεν έχει κύρια εγκατάσταση στην Ένωση, υποβάλλει τις κοινοποιήσεις που αναφέρονται στις παραγράφους 1 και 3 χρησιμοποιώντας το τελικό σημείο ηλεκτρονικής κοινοποίησης της ΟΑΠΑΥ στην οποία έχουν ανατεθεί καθήκοντα συντονισμού στο κράτος μέλος που καθορίζεται σύμφωνα με την ακόλουθη σειρά και με βάση τις πληροφορίες που έχει στη διάθεσή του ο κατασκευαστής:

α) 

το κράτος μέλος στο οποίο είναι εγκατεστημένος ο εξουσιοδοτημένος αντιπρόσωπος που ενεργεί για λογαριασμό του κατασκευαστή για τον μεγαλύτερο αριθμό προϊόντων με ψηφιακά στοιχεία του εν λόγω κατασκευαστή·

β) 

το κράτος μέλος στο οποίο είναι εγκατεστημένος ο εισαγωγέας που θέτει σε κυκλοφορία στην αγορά τον μεγαλύτερο αριθμό προϊόντων με ψηφιακά στοιχεία του εν λόγω κατασκευαστή·

γ) 

το κράτος μέλος στο οποίο είναι εγκατεστημένος ο διανομέας που διαθέτει στην αγορά τον μεγαλύτερο αριθμό προϊόντων με ψηφιακά στοιχεία του εν λόγω κατασκευαστή·

δ) 

το κράτος μέλος στο οποίο βρίσκεται ο μεγαλύτερος αριθμός χρηστών προϊόντων με ψηφιακά στοιχεία του εν λόγω κατασκευαστή.

Όσον αφορά το τρίτο εδάφιο στοιχείο δ), ο κατασκευαστής μπορεί να υποβάλλει κοινοποιήσεις σχετικά με οποιαδήποτε μεταγενέστερη ευπάθεια που αποτελεί αντικείμενο ενεργού εκμετάλλευσης ή οποιοδήποτε μεταγενέστερο σοβαρό περιστατικό που έχει αντίκτυπο στην ασφάλεια του προϊόντος με ψηφιακά στοιχεία στην ίδια ΟΑΠΑΥ στην οποία έχουν ανατεθεί καθήκοντα συντονισμού και στην οποία υπέβαλε αναφορά την πρώτη φορά.
Άρθρο 14 8.
Αφού αντιληφθεί μια ευπάθεια που αποτελεί αντικείμενο ενεργού εκμετάλλευσης ή ένα σοβαρό περιστατικό που έχει αντίκτυπο στην ασφάλεια του προϊόντος με ψηφιακά στοιχεία, ο κατασκευαστής ενημερώνει τους επηρεαζόμενους χρήστες του προϊόντος με ψηφιακά στοιχεία και, κατά περίπτωση, όλους τους χρήστες, σχετικά με την εν λόγω ευπάθεια ή το σοβαρό περιστατικό και, κατά περίπτωση, σχετικά με τυχόν μέτρα μετριασμού του κινδύνου και διορθωτικά μέτρα που μπορούν να λάβουν οι χρήστες για τον μετριασμό των επιπτώσεων της εν λόγω ευπάθειας ή συμβάντος, κατά περίπτωση σε δομημένο και μηχαναγνώσιμο μορφότυπο που μπορεί να υποβληθεί εύκολα σε αυτόματη επεξεργασία. Σε περίπτωση που ο κατασκευαστής δεν ενημερώσει εγκαίρως τους χρήστες του προϊόντος με ψηφιακά στοιχεία, οι κοινοποιημένες ΟΑΠΑΥ στις οποίες έχουν ανατεθεί καθήκοντα συντονισμού μπορούν να παρέχουν τις εν λόγω πληροφορίες στους χρήστες όταν αυτό θεωρείται αναλογικό και αναγκαίο για την πρόληψη ή τον μετριασμό των επιπτώσεων της εν λόγω ευπάθειας ή συμβάντος.
Άρθρο 14 9.
Έως τις 11 Δεκεμβρίου 2025, η Επιτροπή εκδίδει κατ’ εξουσιοδότηση πράξεις σύμφωνα με το άρθρο 61 του παρόντος κανονισμού, για τη συμπλήρωση του παρόντος κανονισμού με τον προσδιορισμό των όρων και προϋποθέσεων για την επίκληση λόγων κυβερνοασφάλειας σε σχέση με την καθυστέρηση της διάδοσης των κοινοποιήσεων, όπως αναφέρεται στο άρθρο 16 παράγραφος 2 του παρόντος κανονισμού. Η Επιτροπή συνεργάζεται με το δίκτυο ΟΑΠΑΥ που συγκροτείται σύμφωνα με το άρθρο 15 της οδηγίας (ΕΕ) 2022/2555, και με τον ENISA κατά την κατάρτιση των σχεδίων κατ’ εξουσιοδότηση πράξεων.
Άρθρο 14 10.
Η Επιτροπή μπορεί, με εκτελεστικές πράξεις, να προσδιορίσει περαιτέρω τον μορφότυπο και τις διαδικασίες των κοινοποιήσεων που αναφέρονται στο παρόν άρθρο, καθώς και στα άρθρα 15 και 16. Οι εν λόγω εκτελεστικές πράξεις εκδίδονται σύμφωνα με τη διαδικασία εξέτασης στην οποία παραπέμπει το άρθρο 62 παράγραφος 2. Η Επιτροπή συνεργάζεται με το δίκτυο ΟΑΠΑΥ και τον ENISA κατά την κατάρτιση των εν λόγω σχεδίων εκτελεστικών πράξεων.

1.1 Παραπομπές

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

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

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

Απαιτήσεις

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

Πρότυπα
SCF Incident Classification & Prioritization

Description

Mechanisms exist to identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.

Possible Solutions & Considerations

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

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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

Incident Response (IRO) 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 IRO 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 IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.

Level 3 Well Defined

Incident Response (IRO) 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 IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management 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 IRO 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 identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.

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 Incident Stakeholder Reporting

Description

Mechanisms exist to timely-report incidents to applicable:
(1) Internal stakeholders;
(2) Affected clients & third-parties; and
(3) Regulatory authorities.

Possible Solutions & Considerations

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

∙ Basic incident response plan
∙ Designate incident response contact

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

∙ Documented incident response plan
∙ Incident log
∙ Designated IR team

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

∙ Formal incident response program
∙ IR playbooks
∙ Tabletop exercises

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

∙ Enterprise incident response program
∙ 24/7 SOC monitoring
∙ SOAR platform

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

∙ Enterprise SOC with SIEM/SOAR (e.g., Splunk SOAR, Palo Alto XSOAR)
∙ IR retainer
∙ Threat hunting

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

Incident Response (IRO) 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 IRO 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 IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.

Level 3 Well Defined

Incident Response (IRO) 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 IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management 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 IRO 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 timely-report incidents to applicable:
(1) Internal stakeholders;
(2) Affected clients & third-parties; and
(3) Regulatory authorities.

Level 4 Quantitatively Controlled

Incident Response (IRO) 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 Cyber Incident Reporting for Sensitive / Regulated Data

Description

Mechanisms exist to report sensitive and/or regulated data incidents in a timely manner.

Possible Solutions & Considerations

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

∙ Incident Response Plan (IRP)

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

∙ Incident Response Plan (IRP)

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

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

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

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

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

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

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

Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.

Level 2 Planned Tracked

Incident Response (IRO) 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 IRO 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 IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.

Level 3 Well Defined

Incident Response (IRO) 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 IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management 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 IRO 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 report sensitive/regulated data incidents in a timely manner.

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 Incident Classification & Prioritization

Description

Mechanisms exist to identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.

Possible Solutions & Considerations

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

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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

Incident Response (IRO) 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 IRO 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 IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.

Level 3 Well Defined

Incident Response (IRO) 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 IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management 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 IRO 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 identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.

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 Incident Stakeholder Reporting

Description

Mechanisms exist to timely-report incidents to applicable:
(1) Internal stakeholders;
(2) Affected clients & third-parties; and
(3) Regulatory authorities.

Possible Solutions & Considerations

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

∙ Basic incident response plan
∙ Designate incident response contact

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

∙ Documented incident response plan
∙ Incident log
∙ Designated IR team

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

∙ Formal incident response program
∙ IR playbooks
∙ Tabletop exercises

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

∙ Enterprise incident response program
∙ 24/7 SOC monitoring
∙ SOAR platform

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

∙ Enterprise SOC with SIEM/SOAR (e.g., Splunk SOAR, Palo Alto XSOAR)
∙ IR retainer
∙ Threat hunting

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

Incident Response (IRO) 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 IRO 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 IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.

Level 3 Well Defined

Incident Response (IRO) 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 IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management 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 IRO 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 timely-report incidents to applicable:
(1) Internal stakeholders;
(2) Affected clients & third-parties; and
(3) Regulatory authorities.

Level 4 Quantitatively Controlled

Incident Response (IRO) 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 Cyber Incident Reporting for Sensitive / Regulated Data

Description

Mechanisms exist to report sensitive and/or regulated data incidents in a timely manner.

Possible Solutions & Considerations

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

∙ Incident Response Plan (IRP)

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

∙ Incident Response Plan (IRP)

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

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

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

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

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

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

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

Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.

Level 2 Planned Tracked

Incident Response (IRO) 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 IRO 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 IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.

Level 3 Well Defined

Incident Response (IRO) 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 IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management 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 IRO 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 report sensitive/regulated data incidents in a timely manner.

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 Disclosure of Vulnerabilities

Description

Mechanisms exist to disclose information about vulnerabilities to relevant stakeholders, including:
(1) A description of the vulnerability(ies);
(2) Affected product(s) and/or service(s);
(3) Potential impact of the vulnerability(ies);
(4) Severity of the vulnerability(ies); and
(5) Guidance to remediate the vulnerability(ies).

Possible Solutions & Considerations

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

∙ Notify customers of vulnerabilities in any developed products via email/website

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

∙ Security advisory template and distribution process
∙ security.txt / contact for vulnerability reports

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

∙ Vulnerability disclosure process with advisories (description, impact, remediation)
∙ Coordinated disclosure timelines

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

∙ Product Security Incident Response Team (PSIRT) disclosure process (ISO/IEC 29147)
∙ CVE issuance for product vulnerabilities
∙ Customer notification channels

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

∙ Enterprise coordinated vulnerability disclosure program (ISO/IEC 29147, CNA participation)
∙ Public advisory portal and machine-readable advisories (CSAF)
∙ Regulatory notification (e.g., EU CRA) 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

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 disclose information about vulnerabilities to relevant stakeholders, including:
(1) A description of the vulnerability(ies);
(2) Affected product(s) and/or service(s);
(3) Potential impact of the vulnerability(ies);
(4) Severity of the vulnerability(ies); and
(5) Guidance to remediate the vulnerability(ies).

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.