+Άρθρο 13 Υποχρεώσεις των κατασκευαστών
---+Άρθρο 13 1.
---+Άρθρο 13 2.
---+Άρθρο 13 3.
---+Άρθρο 13 4.
---+Άρθρο 13 5.
---+Άρθρο 13 6.
---+Άρθρο 13 7.
---+Άρθρο 13 8.
---+Άρθρο 13 9.
---+Άρθρο 13 10.
---+Άρθρο 13 11.
---+Άρθρο 13 12.
---+Άρθρο 13 13.
---+Άρθρο 13 14.
---+Άρθρο 13 15.
---+Άρθρο 13 16.
---+Άρθρο 13 17.
---+Άρθρο 13 18.
---+Άρθρο 13 19.
---+Άρθρο 13 20.
---+Άρθρο 13 21.
---+Άρθρο 13 22.
---+Άρθρο 13 23.
---+Άρθρο 13 24.
---+Άρθρο 13 25.

Άρθρο 13 Υποχρεώσεις των κατασκευαστών

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

Τίτλος	Κανονισμός
Άρθρο 13 1.	Κατά τη διάθεση προϊόντος με ψηφιακά στοιχεία στην αγορά, οι κατασκευαστές εξασφαλίζουν ότι αυτό έχει σχεδιαστεί, αναπτυχθεί και κατασκευαστεί σύμφωνα με τις ουσιώδεις απαιτήσεις κυβερνοασφάλειας που ορίζονται στο παράρτημα I μέρος I.
Άρθρο 13 2.	Για τον σκοπό της συμμόρφωσης με την παράγραφο 1, οι κατασκευαστές διενεργούν εκτίμηση των κινδύνων που σχετίζονται με προϊόν με ψηφιακά στοιχεία όσον αφορά την κυβερνοασφάλεια και λαμβάνουν υπόψη το αποτέλεσμα της εν λόγω αξιολόγησης κατά τα στάδια προγραμματισμού, σχεδιασμού, ανάπτυξης, παραγωγής, παράδοσης και συντήρησης του προϊόντος με ψηφιακά στοιχεία, με σκοπό την ελαχιστοποίηση των κινδύνων για την κυβερνοασφάλεια, την πρόληψη περιστατικών και την ελαχιστοποίηση των επιπτώσεών τους, μεταξύ άλλων στην υγεία και την ασφάλεια των χρηστών.
Άρθρο 13 3.	Η εκτίμηση κινδύνων κυβερνοασφάλειας τεκμηριώνεται και επικαιροποιείται, κατά περίπτωση, κατά τη διάρκεια περιόδου υποστήριξης που καθορίζεται σύμφωνα με την παράγραφο 8 του παρόντος άρθρου. Η εν λόγω εκτίμηση κινδύνων κυβερνοασφάλειας περιλαμβάνει τουλάχιστον ανάλυση των κινδύνων κυβερνοασφάλειας με βάση τον προβλεπόμενο σκοπό και την ευλόγως προβλέψιμη χρήση, καθώς και τους όρους χρήσης, του προϊόντος με ψηφιακά στοιχεία, όπως το επιχειρησιακό περιβάλλον ή τα περιουσιακά στοιχεία που πρέπει να προστατευθούν, λαμβανομένου υπόψη του χρόνου που αναμένεται να χρησιμοποιηθεί το προϊόν. Στην εκτίμηση κινδύνων κυβερνοασφάλειας αναφέρεται κατά πόσον και, εάν ναι, με ποιον τρόπο, οι απαιτήσεις ασφάλειας που ορίζονται στο παράρτημα I μέρος I σημείο 2, εφαρμόζονται στο σχετικό προϊόν με ψηφιακά στοιχεία και πώς εφαρμόζονται οι εν λόγω απαιτήσεις, όπως τεκμηριώνεται από την εκτίμηση κινδύνων κυβερνοασφάλειας. Αναφέρεται επίσης ο τρόπος με τον οποίο ο κατασκευαστής εφαρμόζει το παράρτημα I μέρος I σημείο 1 και τις απαιτήσεις χειρισμού ευπαθειών που ορίζονται στο παράρτημα I μέρος II.
Άρθρο 13 4.	Όταν ο κατασκευαστής θέτει προϊόν με ψηφιακά στοιχεία σε κυκλοφορία στην αγορά, περιλαμβάνει την εκτίμηση κινδύνων κυβερνοασφάλειας που αναφέρεται στην παράγραφο 3 του παρόντος άρθρου στον τεχνικό φάκελο που απαιτείται σύμφωνα με το άρθρο 31 και το παράρτημα VII. Για τα προϊόντα με ψηφιακά στοιχεία όπως αναφέρονται στο άρθρο 12, τα οποία υπόκεινται και σε άλλες νομικές πράξεις της Ένωσης, η εκτίμηση κινδύνων κυβερνοασφάλειας μπορεί να αποτελεί μέρος της εκτίμησης κινδύνου που απαιτείται από τις εν λόγω νομικές πράξεις της Ένωσης. Όταν ορισμένες ουσιώδεις απαιτήσεις κυβερνοασφάλειας δεν εφαρμόζονται στο προϊόν με ψηφιακά στοιχεία, ο κατασκευαστής περιλαμβάνει σαφή σχετική αιτιολόγηση στον εν λόγω τεχνικό φάκελο.
Άρθρο 13 5.	Για τους σκοπούς της συμμόρφωσης με την παράγραφο 1, οι κατασκευαστές επιδεικνύουν τη δέουσα επιμέλεια κατά την ενσωμάτωση δομοστοιχείων που προέρχονται από τρίτους, ώστε τα εν λόγω δομοστοιχεία να μη θέτουν σε κίνδυνο την κυβερνοασφάλεια του προϊόντος με ψηφιακά στοιχεία, μεταξύ άλλων όταν ενσωματώνουν δομοστοιχεία ελεύθερου λογισμικού ανοικτού κώδικα που δεν έχουν καταστεί διαθέσιμα στην αγορά στο πλαίσιο εμπορικής δραστηριότητας.
Άρθρο 13 6.	Οι κατασκευαστές, μόλις εντοπίσουν μια ευπάθεια σε δομοστοιχείο, μεταξύ άλλων σε δομοστοιχείο ανοικτού κώδικα, το οποίο είναι ενσωματωμένο στο προϊόν με ψηφιακά στοιχεία, αναφέρουν την ευπάθεια στο πρόσωπο ή την οντότητα που κατασκευάζει ή συντηρεί το δομοστοιχείο, και αντιμετωπίζουν και αίρουν την ευπάθεια σύμφωνα με τις απαιτήσεις χειρισμού ευπαθειών που ορίζονται στο παράρτημα I μέρος II. Όταν οι κατασκευαστές έχουν αναπτύξει τροποποίηση λογισμικού ή υλισμικού για την αντιμετώπιση της ευπάθειας του εν λόγω δομοστοιχείου, κοινοποιούν τον σχετικό κώδικα ή την τεκμηρίωση στο πρόσωπο ή την οντότητα που κατασκευάζει ή συντηρεί το δομοστοιχείο, κατά περίπτωση σε μηχαναγνώσιμο μορφότυπο.
Άρθρο 13 7.	Οι κατασκευαστές τεκμηριώνουν συστηματικά, κατά τρόπο αναλογικό προς τη φύση και τους κινδύνους για την κυβερνοασφάλεια, τις σχετικές πτυχές κυβερνοασφάλειας που αφορούν τα προϊόντα με ψηφιακά στοιχεία, συμπεριλαμβανομένων των ευπαθειών που υποπίπτουν στην αντίληψή τους και τυχόν σχετικές πληροφορίες που παρέχονται από τρίτους, και, κατά περίπτωση, επικαιροποιούν την εκτίμηση κινδύνων κυβερνοασφάλειας των προϊόντων.
Άρθρο 13 8.	Οι κατασκευαστές εξασφαλίζουν, όταν θέτουν προϊόν με ψηφιακά στοιχεία σε κυκλοφορία στην αγορά, και για την περίοδο υποστήριξης, ότι οι ευπάθειες του εν λόγω προϊόντος, συμπεριλαμβανομένων των δομοστοιχείων του, αντιμετωπίζονται αποτελεσματικά και σύμφωνα με τις ουσιώδεις απαιτήσεις κυβερνοασφάλειας που ορίζονται στο παράρτημα I μέρος II. Οι κατασκευαστές καθορίζουν την περίοδο υποστήριξης κατά τρόπο ώστε αυτή να αντικατοπτρίζει το χρονικό διάστημα κατά το οποίο αναμένεται να χρησιμοποιηθεί το προϊόν, λαμβάνοντας υπόψη, ιδίως, τις εύλογες προσδοκίες των χρηστών, τη φύση του προϊόντος, συμπεριλαμβανομένου του προβλεπόμενου σκοπού του, καθώς και τη σχετική ενωσιακή νομοθεσία που καθορίζει τη διάρκεια ζωής των προϊόντων με ψηφιακά στοιχεία. Κατά τον καθορισμό της περιόδου υποστήριξης, οι κατασκευαστές μπορούν επίσης να λαμβάνουν υπόψη τις περιόδους υποστήριξης προϊόντων με ψηφιακά στοιχεία που προσφέρουν παρόμοια λειτουργικότητα και έχουν τεθεί σε κυκλοφορία στην αγορά από άλλους κατασκευαστές, τη διαθεσιμότητα του περιβάλλοντος λειτουργίας, τις περιόδους υποστήριξης των ενσωματωμένων δομοστοιχείων που παρέχουν βασικές λειτουργίες και προέρχονται από τρίτους, καθώς και τη σχετική καθοδήγηση που παρέχεται από την ειδική ομάδα διοικητικής συνεργασίας (ΕΟΔΚ) που συγκροτείται σύμφωνα με το άρθρο 52 παράγραφος 15 και την Επιτροπή. Τα ζητήματα που πρέπει να λαμβάνονται υπόψη για τον καθορισμό της περιόδου υποστήριξης εξετάζονται κατά τρόπο που διασφαλίζει την αναλογικότητα. Με την επιφύλαξη του δεύτερου εδαφίου, η περίοδος υποστήριξης είναι τουλάχιστον πέντε έτη. Όταν το προϊόν με ψηφιακά στοιχεία αναμένεται να χρησιμοποιηθεί για λιγότερο από πέντε έτη, η περίοδος υποστήριξης αντιστοιχεί στον αναμενόμενο χρόνο χρήσης. Λαμβάνοντας υπόψη τις συστάσεις της ΕΟΔΚ, όπως αναφέρονται στο άρθρο 52 παράγραφος 16, η Επιτροπή μπορεί να εκδίδει κατ’ εξουσιοδότηση πράξεις σύμφωνα με το άρθρο 61, προκειμένου να συμπληρώσει τον παρόντα κανονισμό προσδιορίζοντας την ελάχιστη περίοδο υποστήριξης για συγκεκριμένες κατηγορίες προϊόντων για τις οποίες τα δεδομένα εποπτείας της αγοράς δείχνουν ότι οι περίοδοι υποστήριξης είναι ανεπαρκείς. Οι κατασκευαστές περιλαμβάνουν στον τεχνικό φάκελο, όπως ορίζεται στο παράρτημα VII, τις πληροφορίες που ελήφθησαν υπόψη για τον καθορισμό της περιόδου υποστήριξης ενός προϊόντος με ψηφιακά στοιχεία. Οι κατασκευαστές διαθέτουν κατάλληλες πολιτικές και διαδικασίες, συμπεριλαμβανομένων συντονισμένων πολιτικών γνωστοποίησης ευπαθειών, όπως αναφέρονται στο παράρτημα I μέρος II σημείο 5, για την επεξεργασία και την αποκατάσταση πιθανών ευπαθειών του προϊόντος με ψηφιακά στοιχεία που αναφέρονται από εσωτερικές ή εξωτερικές πηγές.
Άρθρο 13 9.	Οι κατασκευαστές διασφαλίζουν ότι κάθε ενημέρωση ασφαλείας, όπως αναφέρεται στο παράρτημα I μέρος II σημείο 8, η οποία έχει καταστεί διαθέσιμη στους χρήστες κατά τη διάρκεια της περιόδου υποστήριξης, παραμένει διαθέσιμη μετά την έκδοσή της για τουλάχιστον 10 έτη ή για το υπόλοιπο της περιόδου υποστήριξης, ανάλογα με το ποιο διάστημα είναι μεγαλύτερο.
Άρθρο 13 10.	Όταν ένας κατασκευαστής έχει θέσει σε κυκλοφορία στην αγορά μεταγενέστερες ουσιωδώς τροποποιημένες εκδόσεις προϊόντος λογισμικού, ο εν λόγω κατασκευαστής μπορεί να διασφαλίσει τη συμμόρφωση με την ουσιώδη απαίτηση κυβερνοασφάλειας που ορίζεται στο παράρτημα I μέρος II σημείο 2, μόνο για την έκδοση που έθεσε τελευταία σε κυκλοφορία στην αγορά ο εν λόγω κατασκευαστής, υπό την προϋπόθεση ότι οι χρήστες των εκδόσεων που είχαν τεθεί προηγουμένως σε κυκλοφορία στην αγορά, έχουν πρόσβαση στην τελευταία έκδοση που τέθηκε σε κυκλοφορία στην αγορά δωρεάν και δεν επιβαρύνονται με πρόσθετες δαπάνες για την προσαρμογή του περιβάλλοντος υλισμικού και λογισμικού στο οποίο χρησιμοποιούν την αρχική έκδοση του εν λόγω προϊόντος.
Άρθρο 13 11.	Οι κατασκευαστές μπορούν να διατηρούν δημόσια αρχεία λογισμικού που ενισχύουν την πρόσβαση των χρηστών σε ιστορικές εκδόσεις. Στις περιπτώσεις αυτές, οι χρήστες ενημερώνονται σαφώς και με εύκολα προσβάσιμο τρόπο σχετικά με τους κινδύνους που συνδέονται με τη χρήση μη υποστηριζόμενου λογισμικού.
Άρθρο 13 12.	Πριν από τη διάθεση προϊόντος με ψηφιακά στοιχεία στην αγορά, οι κατασκευαστές καταρτίζουν τον τεχνικό φάκελο που αναφέρεται στο άρθρο 31. Διενεργούν τις επιλεγμένες διαδικασίες αξιολόγησης της συμμόρφωσης όπως αναφέρονται στο άρθρο 32 ή αναθέτουν τη διενέργειά τους σε τρίτους. Όταν η συμμόρφωση του προϊόντος με ψηφιακά στοιχεία με τις ουσιώδεις απαιτήσεις κυβερνοασφάλειας που καθορίζονται στο παράρτημα I μέρος I, και των διαδικασιών που εφαρμόζει ο κατασκευαστής με τις ουσιώδεις απαιτήσεις κυβερνοασφάλειας που ορίζονται στο τμήμα 2 του παραρτήματος I μέρος II, αποδεικνύεται με την εν λόγω διαδικασία αξιολόγησης της συμμόρφωσης, οι κατασκευαστές καταρτίζουν τη δήλωση συμμόρφωσης ΕΕ σύμφωνα με το άρθρο 28 και τοποθετούν τη σήμανση CE σύμφωνα με το άρθρο 30.
Άρθρο 13 13.	Οι κατασκευαστές διατηρούν τον τεχνικό φάκελο και τη δήλωση συμμόρφωσης ΕΕ στη διάθεση των αρχών εποπτείας της αγοράς τουλάχιστον επί δέκα έτη αφότου το προϊόν με ψηφιακά στοιχεία τεθεί σε κυκλοφορία στην αγορά ή για την περίοδο υποστήριξης, ανάλογα με το ποιο διάστημα είναι μεγαλύτερο.
Άρθρο 13 14.	Οι κατασκευαστές διασφαλίζουν ότι εφαρμόζονται διαδικασίες ώστε τα προϊόντα με ψηφιακά στοιχεία που αποτελούν μέρος σειράς παραγωγής να συμμορφώνονται διαρκώς με τον παρόντα κανονισμό. Οι κατασκευαστές λαμβάνουν δεόντως υπόψη τις αλλαγές στη διαδικασία ανάπτυξης και παραγωγής ή στον σχεδιασμό ή τα χαρακτηριστικά του προϊόντος με ψηφιακά στοιχεία, καθώς και τις αλλαγές στα εναρμονισμένα πρότυπα, στα ευρωπαϊκά καθεστώτα πιστοποίησης της κυβερνοασφάλειας ή στις κοινές προδιαγραφές όπως αναφέρονται στο άρθρο 27 και με βάση τις οποίες δηλώνεται η συμμόρφωση του προϊόντος με ψηφιακά στοιχεία ή με την εφαρμογή των οποίων επαληθεύεται η συμμόρφωσή του.
Άρθρο 13 15.	Οι κατασκευαστές διασφαλίζουν ότι τα προϊόντα τους με ψηφιακά στοιχεία φέρουν αριθμό τύπου, παρτίδας ή σειράς ή άλλο στοιχείο που επιτρέπει την ταυτοποίησή τους ή, όταν αυτό δεν είναι δυνατό, ότι οι εν λόγω πληροφορίες αναγράφονται στη συσκευασία τους ή σε έγγραφο που συνοδεύει το προϊόν με ψηφιακά στοιχεία.
Άρθρο 13 16.	Οι κατασκευαστές αναγράφουν το όνομα, την καταχωρισμένη εμπορική επωνυμία ή το καταχωρισμένο εμπορικό σήμα του κατασκευαστή, και την ταχυδρομική διεύθυνση, τη διεύθυνση ηλεκτρονικού ταχυδρομείου ή άλλα ψηφιακά στοιχεία επικοινωνίας, καθώς και, κατά περίπτωση, τον ιστότοπο μέσω του οποίου μπορεί να υπάρξει επικοινωνία με τον κατασκευαστή, στο προϊόν με ψηφιακά στοιχεία, στη συσκευασία του ή σε έγγραφο που συνοδεύει το προϊόν με ψηφιακά στοιχεία. Οι πληροφορίες αυτές περιλαμβάνονται επίσης στις πληροφορίες και τις οδηγίες προς τον χρήστη που ορίζονται στο παράρτημα II. Τα στοιχεία επικοινωνίας παρέχονται σε γλώσσα εύκολα κατανοητή από τους χρήστες και τις αρχές εποπτείας της αγοράς.
Άρθρο 13 17.	Για τους σκοπούς του παρόντος κανονισμού, οι κατασκευαστές ορίζουν ενιαίο σημείο επαφής που επιτρέπει στους χρήστες να επικοινωνούν απευθείας και γρήγορα μαζί τους, μεταξύ άλλων προκειμένου να διευκολύνεται η αναφορά ευπαθειών του προϊόντος με ψηφιακά στοιχεία. Οι κατασκευαστές εξασφαλίζουν ότι το ενιαίο σημείο επαφής μπορεί να αναγνωριστεί εύκολα από τους χρήστες. Περιλαμβάνουν επίσης το ενιαίο σημείο επαφής στις πληροφορίες και τις οδηγίες προς τον χρήστη που ορίζονται στο παράρτημα II. Το ενιαίο σημείο επαφής επιτρέπει στους χρήστες να επιλέγουν τα μέσα επικοινωνίας που προτιμούν και δεν περιορίζει τα μέσα αυτά σε αυτοματοποιημένα εργαλεία.
Άρθρο 13 18.	Οι κατασκευαστές διασφαλίζουν ότι τα προϊόντα με ψηφιακά στοιχεία συνοδεύονται από τις πληροφορίες και τις οδηγίες προς τον χρήστη που ορίζονται στο παράρτημα II, σε έντυπη ή ηλεκτρονική μορφή. Οι εν λόγω πληροφορίες και οδηγίες παρέχονται σε γλώσσα εύκολα κατανοητή από τους χρήστες και τις αρχές εποπτείας της αγοράς. Είναι σαφείς, κατανοητές, εύληπτες και ευανάγνωστες. Επιτρέπουν την ασφαλή εγκατάσταση, λειτουργία και χρήση των προϊόντων με ψηφιακά στοιχεία. Οι κατασκευαστές διατηρούν τις πληροφορίες και τις οδηγίες προς τον χρήστη που ορίζονται στο παράρτημα II στη διάθεση των χρηστών και των αρχών εποπτείας της αγοράς τουλάχιστον επί δέκα έτη αφότου το προϊόν με ψηφιακά στοιχεία τεθεί σε κυκλοφορία στην αγορά ή για την περίοδο υποστήριξης, ανάλογα με το ποιο διάστημα είναι μεγαλύτερο. Όταν οι εν λόγω πληροφορίες και οδηγίες παρέχονται διαδικτυακά, οι κατασκευαστές εξασφαλίζουν ότι είναι προσβάσιμες, εύχρηστες και διαθέσιμες διαδικτυακά επί τουλάχιστον δέκα έτη αφότου το προϊόν με ψηφιακά στοιχεία τεθεί σε κυκλοφορία στην αγορά ή για την περίοδο υποστήριξης, ανάλογα με το ποιο διάστημα είναι μεγαλύτερο.
Άρθρο 13 19.	Οι κατασκευαστές διασφαλίζουν ότι η ημερομηνία λήξης της περιόδου υποστήριξης που αναφέρεται στην παράγραφο 8, συμπεριλαμβανομένου τουλάχιστον του μήνα και του έτους, προσδιορίζεται σαφώς και κατανοητά κατά τη στιγμή της αγοράς, με εύκολα προσβάσιμο τρόπο και, κατά περίπτωση, στο προϊόν με ψηφιακά στοιχεία, στη συσκευασία του ή με ψηφιακά μέσα. Όπου είναι τεχνικά εφικτό λόγω της φύσης του προϊόντος με ψηφιακά στοιχεία, οι κατασκευαστές εμφανίζουν κοινοποίηση προς τους χρήστες με την οποία τους ενημερώνουν ότι το προϊόν τους με ψηφιακά στοιχεία έχει φτάσει στο τέλος της περιόδου υποστήριξής του.
Άρθρο 13 20.	Οι κατασκευαστές παρέχουν είτε αντίγραφο της δήλωσης συμμόρφωσης ΕΕ είτε απλουστευμένη δήλωση συμμόρφωσης ΕΕ με το προϊόν με ψηφιακά στοιχεία. Στην περίπτωση που παρέχεται απλουστευμένη δήλωση συμμόρφωσης ΕΕ, αυτή περιλαμβάνει την ακριβή διαδικτυακή διεύθυνση στην οποία διατίθεται πρόσβαση στο πλήρες κείμενο της δήλωσης συμμόρφωσης ΕΕ.
Άρθρο 13 21.	Από τη διάθεση στην αγορά και για την περίοδο υποστήριξης, οι κατασκευαστές που γνωρίζουν ή έχουν λόγους να πιστεύουν ότι το προϊόν με ψηφιακά στοιχεία ή οι διαδικασίες που εφαρμόζει ο κατασκευαστής δεν συμμορφώνονται με τις ουσιώδεις απαιτήσεις κυβερνοασφάλειας που ορίζονται στο παράρτημα I, λαμβάνουν αμέσως τα αναγκαία διορθωτικά μέτρα για να εξασφαλίσουν τη συμμόρφωση του προϊόντος με ψηφιακά στοιχεία ή των διαδικασιών του κατασκευαστή, ή να αποσύρουν ή να ανακαλέσουν το προϊόν, κατά περίπτωση.
Άρθρο 13 22.	Οι κατασκευαστές παρέχουν στην αρχή εποπτείας της αγοράς, κατόπιν αιτιολογημένου αιτήματος της εν λόγω αρχής, σε γλώσσα εύκολα κατανοητή από την εν λόγω αρχή, όλες τις πληροφορίες και την τεκμηρίωση που απαιτούνται, σε έντυπη ή ηλεκτρονική μορφή, για να αποδειχθεί η συμμόρφωση του προϊόντος με ψηφιακά στοιχεία και των διαδικασιών που εφαρμόζει ο κατασκευαστής προς τις ουσιώδεις απαιτήσεις κυβερνοασφάλειας που ορίζονται στο παράρτημα I. Οι κατασκευαστές συνεργάζονται με την εν λόγω αρχή, κατόπιν αιτήματός της, για τυχόν μέτρα που λαμβάνονται για την εξάλειψη των κινδύνων που ενέχει το προϊόν με ψηφιακά στοιχεία το οποίο έχουν διαθέσει στην αγορά, όσον αφορά την κυβερνοασφάλεια.
Άρθρο 13 23.	Ο κατασκευαστής που παύει τις δραστηριότητές του και, ως εκ τούτου, δεν είναι σε θέση να συμμορφωθεί με τον παρόντα κανονισμό ενημερώνει, πριν από την έναρξη ισχύος της παύσης των δραστηριοτήτων του, τις αρμόδιες αρχές εποπτείας της αγοράς, καθώς και τους χρήστες των σχετικών προϊόντων με ψηφιακά στοιχεία που έχουν τεθεί σε κυκλοφορία στην αγορά, με κάθε διαθέσιμο μέσο και στο μέτρο του δυνατού, σχετικά με την επικείμενη παύση των δραστηριοτήτων του.
Άρθρο 13 24.	Η Επιτροπή μπορεί, με εκτελεστικές πράξεις και λαμβάνοντας υπόψη τα ευρωπαϊκά ή διεθνή πρότυπα και βέλτιστες πρακτικές, να καθορίζει τον μορφότυπο και τα στοιχεία του καταλόγου υλικών λογισμικού που αναφέρεται στο παράρτημα I μέρος II σημείο 1. Οι εν λόγω εκτελεστικές πράξεις εκδίδονται σύμφωνα με τη διαδικασία εξέτασης στην οποία παραπέμπει το άρθρο 62 παράγραφος 2.
Άρθρο 13 25.	Προκειμένου να αξιολογηθεί η εξάρτηση των κρατών μελών και της Ένωσης στο σύνολό της από δομοστοιχεία λογισμικού και ιδίως από δομοστοιχεία που χαρακτηρίζονται ως ελεύθερο λογισμικό ανοικτού κώδικα, η ΕΟΔΚ μπορεί να αποφασίσει να διενεργήσει αξιολόγηση της εξάρτησης σε επίπεδο Ένωσης για συγκεκριμένες κατηγορίες προϊόντων με ψηφιακά στοιχεία. Για τον σκοπό αυτό, οι αρχές εποπτείας της αγοράς μπορούν να ζητήσουν από τους κατασκευαστές των εν λόγω κατηγοριών προϊόντων με ψηφιακά στοιχεία να παράσχουν τους σχετικούς καταλόγους υλικών λογισμικού, όπως αναφέρεται στο παράρτημα I μέρος II σημείο 1. Βάσει των εν λόγω πληροφοριών, οι αρχές εποπτείας της αγοράς μπορούν να παράσχουν στην ΕΟΔΚ ανωνυμοποιημένες και συγκεντρωτικές πληροφορίες σχετικά με τις εξαρτήσεις λογισμικού. Η ΕΟΔΚ υποβάλλει έκθεση σχετικά με τα αποτελέσματα της αξιολόγησης εξάρτησης στην ομάδα συνεργασίας που συγκροτείται σύμφωνα με το άρθρο 14 της οδηγίας (ΕΕ) 2022/2555.

1.1 Παραπομπές

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

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

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

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

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

Πρότυπα
Πηγή	Απαίτηση
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.

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

Άρθρο 13 Υποχρεώσεις των κατασκευαστών

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

1.1 Παραπομπές

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

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

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

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

Description

Possible Solutions & Considerations

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

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

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

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

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

SCR-CMM

Level 0 Not Performed

Level 1 Performed Informally

Level 2 Planned Tracked

Level 3 Well Defined

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

Description

Possible Solutions & Considerations

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

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

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

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

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

SCR-CMM

Level 0 Not Performed

Level 1 Performed Informally

Level 2 Planned Tracked

Level 3 Well Defined

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

Description

Possible Solutions & Considerations

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

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

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

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

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

SCR-CMM

Level 0 Not Performed

Level 1 Performed Informally

Level 2 Planned Tracked

Level 3 Well Defined

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

Description

Possible Solutions & Considerations

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

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

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

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

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

SCR-CMM

Level 0 Not Performed

Level 1 Performed Informally

Level 2 Planned Tracked

Level 3 Well Defined

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

Description

Possible Solutions & Considerations

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

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

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

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

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

SCR-CMM

Level 0 Not Performed

Level 1 Performed Informally

Level 2 Planned Tracked

Level 3 Well Defined

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

Description

Possible Solutions & Considerations

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